List, I have IUP running in a multi-threaded environment under Script BASIC on Ubuntu 14.04 LTS 64 bit.
http://www.scriptbasic.org/forum/index.php/topic,335.msg1490.html#msg1490 It works but not stable. I need to let Gtk know that my callbacks needed to be more thread friendly. I have scoured the web looking for a solution. There is a lot of advice but no code examples or consistency with a direction. I have found two references that sound promising. I feel if we can agree on a solution, it would benefit all IUP users no matter what the binding is. Here is a post on the IUP list by 'Otfried' Note that in GTK this is really easy to achieve: GLib is thread-safe, and so you can simply call g_idle_add from your worker thread to register an idle callback. The idle callback will then be called from the GTK main loop in the IUP thread (since IUP simply uses the GTK main loop, all this should work seamlessly without any modification to IUP). --------------------------------------------------------------------- Antonio Scuri wrote: > The IUP 3 GTK driver implements the Idle callback using g_idle_add, but it > has the same effect as in the Windows driver. The Motif driver also uses a > native X-Windows idle system, but the effect is also the same. I did a few > tests at the time I implement it. > > The effect is that the CPU consuming is very high, I mean the idle is > called all the time. Why? When the mouse moves it should be NOT an "idle" > time, but in fact it is. Weird but it is true. Between each mouse move there > is a few milliseconds that there is no event to be processed, and the idle > callback is then called between the move. Having an active idle callback is very time consuming, so you should not try to have an idle callback to poll for completion for another thread. However, using 'g_idle_add' to signal completion (or to signal anything) from a worker thread to the main thread works differently - it is very CPU-efficient, and is in fact the recommended and standard way of doing this using GTK/GLib. The way it works is this: Your main thread is running the user interface, and is always waiting inside a gtk_main_loop unless it is currently updating the UI. When the worker thread has to signal something (for instance that it has finished the work), it registers a callback function using 'g_idle_add'. This will cause the main thread to wake up from the gtk_main_loop and to execute this callback function - it can collect the data from the worker thread and display it on the UI. The callback function returns FALSE, and therefore unregisters itself immediately - so it is only run one single time. This is why this is very efficient. As I said, I think this is how one is supposed to do this in GTK, and it can be implemented elegantly without changing IUP at all. So I think extra methods for this should _not_ be added to IUP for the GTK case. In any case, if you are using threading in your application, you have to use platform-specific code for the threading. IUP should concentrate on remaining a UI-library, and not try to offer platform-independent threading support (like some monster libraries like Qt do...) However, it doesn't seem that something like this is possible in Windows, and it would be nice if IUP had the necessary features that make signaling from a worker thread possible in Windows. > Giving a quick look at Glib I found "Asynchronous Queues" > (g_async_queue_*) that seems to be what we want. But I'm not sure. Asynchronous queues can be used to safely send data from one thread to another without worrying about locking (it does that automatically). However, to use this, the receiving thread still needs to check whether data has arrived in the queue, so you need a way to wake up the IUP thread when data is ready in the queue. Again, the point is that the main thread is blocking inside a gtk_main_loop, and one needs a mechanism to wake it up. Cheers, Otfried --------------------------------------------------------------------- Another post I found that take a different direction which seems to address exactly what I'm doing. What's the difference between calling g_idle_add and returning FALSE from its call back and just using g_main_context_invoke? g_main_context_invoke is a recent addition (GLib 2.28) that appears to be meant for use with multiple mainloops on different threads. There is no reason not to use g_idle_add when dealing with the default MainContext. Thanks in advance for ANY direction you are willing to offer to help me resolve this and bring threaded IUP support for all. John ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
