Hello, My program was already written using single thread and approach you described (using g_idle_add and poll). One of the functions of the program is audio transmission (to and from network-connected hardware device using special protocol), and it is required to receive and send packets with specific maximum latencies (this is not real-time because maximum latencies are big), and without GUI it works very well. But when doing something in GUI (for example scrolling with mouse wheel) the latencies become too big - I think this is because GTK takes a lot of time in the callbacks without returning to the main loop. So I've decided to rewrite the program using two threads - one for network-related things and one for GUI. I do not see any other solution, but may be this is because I'm not expert in GTK (and GUI) programming. Anyway, any hints are welcome.
P.S. I've been at holiday this week, so I couldn't reply earlier. Gus Koppel wrote: > Vladimir wrote: > >> There are two uses of GTK+ in non-main threads: >> 1. error reporting via message boxes and >> 2. adding text (which comes from network) to GUI windows. > > Btw, if you don't use modal message box dialogs then there is absolutely > no need to use multiple threads (aka one to receive, the other one to > display) at all. One single thread can perfectly handle this chain of > actions: > - wait for data from network and receive into buffer if there's any > - add received buffer data to a text display > - open a (non-modal) message box to report errors if there are any > > The non-modality of the dialog assures that reception anmd display of > incoming data would continue at the same time. For instance, if you use > select() or poll() to wait for network data in the other thread, better > have a look at this: > > http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#GSource > http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-source-add-poll > > This way you can do completely without multiple threads for all sorts of > asynchronous I/O regarding network traffic and GTK+ visualization. Doing > without threads is always easier to debug and also prevents creating > some hard to find bugs while writing the code. > > Unless your application includes massive computations of data (in which > multiple threads can be beneficial on multi-core systems, indeed), > single-threaded apps may also save a tiny amount of CPU time and code > size, since there is no need for thread switches and mutexes and all > that stuff. So, if there are no other reasons for multiple threads than > being able to receive and display "simultaneously", you should perhaps > consider to abandon the multi-threadity of your application at all? -- Vladimir _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
