In the GObject Reference Manual, it denotes that for a function:
g_signal_connect(instance, detailed_signal, c_handler, data)
A detailed_signal string parameter of form "signal-name::detail" is desired. My initial understanding of that is that there are predefined signal details to pass in. If that is the case, where can I find a list of these? If not, then what exactly does it mean, as the manual doesn't make that too terribly obvious.
The ::detail part of the signal name is optional. If a signal takes a detail parameter, then it will say so in the signal's documentation. Otherwise you can ignore it.
The only signal that I'm aware of that actually uses a detail parameter, is the notify signal of GObject. The notify signal without a detail fires whenever any property changes on the object, so it's fairly useless. But if you connect to the notify::visible signal, then it will fire whenever the object's visible property changes.
Unless things have changed a lot recently, there's no complete, official list of signals. The predefined signals depend entirely on what technologies you're using.
What you can do is look at the online documentation for the GObject instance classes you're working with. For instance, if you're working with GtkButton, you can look it up online and find out that it emits six signals (activate, clicked, enter, leave, pressed, released). GtkButton is derived from GtkContainer, which also emits several documented signals that can potentially be emitted by GtkButton. And GtkContainer is derived from GtkWidget, which emits many documented signals which can potentially be emitted by GtkButton.
If you find an object isn't emitting a kind of signal you expect, you might also look in the source code for that object, because sometimes objects emit undocumented signals,
Related
Both functions of WindowedStream: .apply and .process has the same description. The only difference I've found was that: .apply receives Context whereas .proccess receives Window.
What should one consider when deciding between apply and process?
The newer process method is passed a Context, which contains the Window and other useful fields. This subsumes the apply method, which is passed the Window. There is no good reason to use apply, it has simply been retained for backwards compatibility.
I'm learning about MQTT (specifically the paho C library) by reading and experimenting with variations on the async pub/sub examples.
What's the difference between the MQTTAsync_deliveryComplete callback that you set with MQTTAsync_setCallbacks() vs. the MQTTAsync_onSuccess or MQTTAsync_onSuccess5 callbacks that you set in the MQTTAsync_responseOptions struct that you pass to MQTTAsync_sendMessage() ?
All seem to deal with "successful delivery" of published messages, but from reading the example code and doxygen, I can't tell how they relate to or conflict with or supplement each other. Grateful for any guidance.
Basically MQTTAsync_deliveryComplete and MQTTAsync_onSuccess do the same, they notify you via callback about the delivery of a message. Both callbacks are executed asynchronously on a separate thread to the thread on which the client application is running.
(Both callbacks are even using the same thread in the case of the current version of the Paho client, but this is a non-documented implementation detail. This thread used by MQTTAsync_deliveryComplete and MQTTAsync_onSuccess is of course not the application thread otherwise it would not be an asynchronous callback).
The difference is that MQTTAsync_deliveryComplete callback is set once via MQTTAsync_setCallbacks and then you are informed about every delivery of a message.
In contrast to this, the MQTTAsync_onSuccess informs you once for exactly the message that you send out via MQTTAsync_sendMessage().
You can even define both callbacks, which will both be called when a message is delivered.
This gives you the flexibility to choose the approach that best suits your needs.
Artificial example
Suppose you have three different functions, each sending a specific type of message (e.g. sendTemperature(), sendHumidity(), sendAirPressure()) and in each function you call MQTTAsync_sendMessage, and after each delivery you want to call a matching callback function, then you would choose MQTTAsync_onSuccess. Then you do not need to keep track of MQTTAsync_token and associate that with your callbacks.
For example, if you want to implement a logging function instead, it would be more useful to use MQTTAsync_deliveryComplete because it is called for every delivery.
And of course one can imagine that one would want to have both the specific one with some actions and the generic one for logging, so in this case both variants could be used at the same time.
Documentation
You should note that MQTTAsync_deliveryComplete explicitly states in its documentation that it takes into account the Quality of Service Set. This is not the case in the MQTTAsync_onSuccess documentation, but of course it does not mean that this is not done in the implementation. But if this is important, you should explicitly check the source code.
I am creating example of broadcast and emit. How it is internally maintain broadcast event lists. Also how angularjs identify which on method it should be executed when broadcast event is called.
Us I know If you defined multiple functions on one event,AngularJs will trigger only one function.The last you defined.If you call $broadcast('anyEvent'),angularjs will send a signal down to current scope (from where you called).It collects all listeners and event by name and easily calls it.The same thing with $emit,but only to up from scope (not to down)
I'd leave this in the comment section if my reputation allowed it, but I just started becoming an active member on StackOverflow...
Anyway, I myself am not too familiar with implementing Broadcast/Emit functionality within Angular but I did happen to come across, what I thought, was a very well written article on the matter. Hope this helps!
http://www.oakwoodsys.com/angularjs-using-emit-broadcast-open-controller-communication/
I have an WPF application which contains many classes that support INotifyProprtyChange interface. The property on this classes are changed at high rate from different threads and the problem is that in some cases application UI thread hangs , along with the UI thread other threads that have code calling PropertyChange also hangs while trying update properties.
I did a deadlock check with Windbg but it could detect none.
Now i looked at the stack trace of the threads holding locks and what i always see is that at least one same or different thread has
00000000002d0ab8 000000007712908a [HelperMethodFrame_1OBJ: 00000000002d0ab8] System.Threading.SynchronizationContext.WaitHelper(IntPtr[], Boolean, Int32)
00000000002d13b0 000000007712908a [GCFrame: 00000000002d13b0]
00000000002d16c8 000000007712908a [HelperMethodFrame_1OBJ: 00000000002d16c8] System.Threading.ReaderWriterLock.AcquireReaderLockInternal(Int32)
00000000002d17f0 000007fef1bcf1a0 MS.Internal.ReaderWriterLockWrapper.get_ReadLock()
00000000002d1830 000007fef1ba8d44 System.ComponentModel.PropertyChangedEventManager.OnPropertyChanged(System.Object, System.ComponentModel.PropertyChangedEventArgs)
and another
000000001f64d138 000000007738186a [HelperMethodFrame_1OBJ: 000000001f64d138] System.Threading.ReaderWriterLock.AcquireReaderLockInternal(Int32)
000000001f64d260 000007fef1bcf1a0 MS.Internal.ReaderWriterLockWrapper.get_ReadLock()
000000001f64d2a0 000007fef1ba8d44 System.ComponentModel.PropertyChangedEventManager.OnPropertyChanged(System.Object, System.ComponentModel.PropertyChangedEventArgs)
So its looks like PropertyChangedEventManager wait for some thread to complete while other threads wait to acquire lock?
Now i am having troubles figuring out why this occurs as its sporadic and usually happens when there is many property change events. From what i see other threads in application that not calling property change continue to run normally.
As far as I know PropertyNotifyChanged is only supported in the UI thread.
Just guessing. In bigger environments one problem happends quiet easy: 2 properties update each other endlessly. The setter of prop A calls the setter of prop B which in turn calls the setter of A again. Usually of course not that obvious as described but could be worth to look at.
I'm sure there is a good (or at least decent) reason for this. What is it?
I think this is a brilliant question -
and I think there is need of a better
answer.
Surely the only reason is that there
is something in a framework somewhere
that isn't very thread-safe.
That "something" is almost every single instance member on every single control in System.Windows.Forms.
The MSDN documentation for many controls in System.Windows.Forms, if not all of them, say "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."
This means that instance members such as TextBox.Text {get; set;} are not reentrant.
Making each of those instance members thread safe could introduce a lot of overhead that most applications do not need. Instead the designers of the .Net framework decided, and I think correctly, that the burden of synchronizing access to forms controls from multiple threads should be put on the programmer.
[Edit]
Although this question only asks "why" here is a link to an article that explains "how":
How to: Make Thread-Safe Calls to Windows Forms Controls on MSDN
http://msdn.microsoft.com/en-us/library/ms171728.aspx
Because you can easily end up with a deadlock (among other issues).
For exmaple, your secondary thread could be trying to update the UI control, but the UI control will be waiting for a resource locked by the secondary thread to be released, so both threads end up waiting for each other to finish. As others have commented this situation is not unique to UI code, but is particularly common.
In other languages such as C++ you are free to try and do this (without an exception being thrown as in WinForms), but your application may freeze and stop responding should a deadlock occur.
Incidentally, you can easily tell the UI thread that you want to update a control, just create a delegate, then call the (asynchronous) BeginInvoke method on that control passing it your delegate. E.g.
myControl.BeginInvoke(myControl.UpdateFunction);
This is the equivalent to doing a C++/MFC PostMessage from a worker thread
Although it sounds reasonable Johns answer isn't correct. In fact even when using Invoke you're still not safe not running into dead-lock situations. When dealing with events fired on a background thread using Invoke might even lead to this problem.
The real reason has more to do with race conditions and lays back in ancient Win32 times. I can't explain the details here, the keywords are message pumps, WM_PAINT events and the subtle differences between "SEND" and "POST".
Further information can be found here here and here.
Back in 1.0/1.1 no exception was thrown during debugging, what you got instead was an intermittent run-time hanging scenario. Nice! :)
Therefore with 2.0 they made this scenario throw an exception and quite rightly so.
The actual reason for this is probably (as Adam Haile states) some kind of concurrency/locky issue.
Note that the normal .NET api (such as TextBox.Text = "Hello";) wraps SEND commands (that require immediate action) which can create issues if performed on separate thread from the one that actions the update. Using Invoke/BeginInvoke uses a POST instead which queues the action.
More information on SEND and POST here.
It is so that you don't have two things trying to update the control at the same time. (This could happen if the CPU switches to the other thread in the middle of a write/read)
Same reason you need to use mutexes (or some other synchronization) when accessing shared variables between multiple threads.
Edit:
In other languages such as C++ you are
free to try and do this (without an
exception being thrown as in
WinForms), but you'll end up learning
the hard way!
Ahh yes...I switch between C/C++ and C# and therefore was a little more generic then I should've been, sorry... He is correct, you can do this in C/C++, but it will come back to bite you!
There would also be the need to implement synchronization within update functions that are sensitive to being called simultaneously. Doing this for UI elements would be costly at both application and OS levels, and completely redundant for the vast majority of code.
Some APIs provide a way to change the current thread ownership of a system so you can temporarily (or permanently) update systems from other threads without needing to resort to inter-thread communication.
Hmm I'm not pretty sure but I think that when we have a progress controls like waiting bars, progress bars we can update their values from another thread and everything works great without any glitches.