I have an update on my progress with IUP and threading. For the most part IUP is working on Linux 64 bit in a threaded mode. The minor issue I have run into is I get some sort of Gtk initializations issue in the second thread where the window will open in maximum mode rather that the defined size (like it's sister thread-1) and sometimes missing the min/max system menu button. When this happens (1 out 10 or so times), additional runs will sometime cause a core dump. If I 'reset' the terminal this seems to help restore future runs. I think this gets back to letting Gtk know it's running in threaded mode. I'm pretty happy as so far without informing Gtk or IUP that it's running in threaded mode.
Any thoughts from the list on this would be appreciated. See www.scriptbasic.org/forum for latest examples. On Sun, 2015-05-24 at 11:21 -0700, John Spikowski wrote: > 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 ------------------------------------------------------------------------------ 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
