Re: [gtk-list] Re: multithreaded apps

[Paul Barton-Davis <pbd op net>]

>Paul Barton-Davis wrote:
>> 
>> using gdk_threads_{enter,leave} is fine if you don't have performance
>> considerations that might be affected by the X event loop.
>
>What do you mean by this ? That my threaded app will have to wait gtk to
>finish processing all the pending events ? If this is the performance
>thing I have to consider, then it is ok: I don't mind about this, it is
>not that critical. If you ment something else, please explain me a bit
>more: multi-threaded stuff still a bit unclear to me. Actually, this
>small example is my first attempt to do such a thing in linux.

Consider the case where your UI thread is busy with a callback,
possibly deep in your own UI code, doing who knows what.

At that moment, some external event, or the end of a timer interval,
means that a second thread would really love to be doing something
else, something that also involves interacting with the UI.

So, you call gdk_threads_enter(). And now you wait ... and you wait
... and you wait ... until it is safe for you to proceed, which will
be at some point as the UI thread returns from the callback.

I considered this unacceptable for the program I'm working on now.
Instead, I queue messages to the UI thread, and then signal them
asynchronously by writing to the signal pipe, as my code
demonstrated. This allows the second thread to get on with its work
without waiting for the UI thread to be in a "safe" place.

The simplest example is writing an information message to the user. If
the UI thread is busy with an extensive callback, there is no telling
how long it might be until another thread can get the GTK+ lock and do
whatever it needs to display its message.

For many programs, this isn't a big deal, but for soft-realtime
applications, its a different story.

--p