Re: gdk_threads_leave in gtk callback ?

[Vladimir <kv11111 mail ru>]

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