Re: thread-safety (was: gtk_timeout_add)

["Christopher T. Lansdown" <lansdoct screech cs alfred edu>]

>   Ah, I see.  Would it be possible for the next iteration of GTK+ to do
> preprocessor magic along the lines of..
> 
> #ifdef _REENTRANT
> #define gtk_widget_activate(wid) \
>    { gdk_threads_enter(); gtk_widget_activate(wid); gdk_threads_leave(); }
> #endif
> 
>  ... or would it be too much trouble and destroy readability of the headers?
Actually, it could be kept in a separate header file called something like
gtkreentrant.h, but it would increase pre-processor time and hence compile
time quite a bit.  The other thing is that it really isn't as efficient in
many cases.  Consider this:

length = get_integer();
snprintf(string, len, "Retrieved %i bytes of %i", length, total);
snprintf(string1, len1, "%i", length);
gdk_threads_enter();
gtk_progress_bar_etc(stuff);
gtk_entry_set_text(stuff);
gtk_status_bar_add_etc(stuff);
gdk_threads_leave();

or

...
gdk_threads_enter();
gtk_progress_bar_etc(stuff);
gdk_threads_leave();
gdk_threads_enter();
gtk_entry_set_text(stuff);
gdk_threads_leave();
gdk_threads_enter();
gtk_status_bar_add_etc(stuff);
gdk_threads_leave();

Which is what you would get with your version.  As well, one doesn't need
locking while it is guaranteed that no threads but the main one exist,
such as during startup before any threads have been started.  This is a
big time for a lot of gtk calls, and it would be a performance hit if
every one of them were to call gdk_threads_enter() and gdk_threads_leave()
around it while there are definitely no threads to protect against.

Personally I like the current method because it leaves things being
efficient and doesn't take much effort to do.  On a less important level
it also reminds you that you are in a multi-threaded model and to mutex
your data, as well.

It's a tradeoff, to be sure, but I prefer to have the extra control and to
optimize my code a bit more than to assume that every call is pretty
independent.  Maybe this isn't perfect, but then again, Gtk+ is very fast,
and there's no reason to unnecessarily slow it down just becuase you're
using threads.


Also, that doesn't cut it when you are using Gtk+ wrappers that wouldn't
have been compiled with the _REENTRANT macro and thus need
gdk_threads_enter() and gdk_threads_leave() around them anyhow.  Like
Gnome, for example. :-)

When you get down to it though, most reasons for multi-threading are
because you're doing a lot of non-gtk work.  If that's the case, you're
probably not going to need to do all that much gtk stuff in your non-main
threads and so the extra typing is minimal.  In your main thread you can
probably afford to use big locks (like at the start and end of a callback,
which I think is actually done for you anyhow when you're dealing with a
gtk callback) because what you're doing is relatively fast anyhow, or at
least if the update of your work thread is .15 seconds late, it's not that
big a deal.

Not perfect, definitely.  Not the easiest, true.  But on the other hand
it's more efficient than doing locking on every call.  I personally think
that the tradeoff is worth it.

Hell, if the typing bothers you that much, you can always do
#define GTE gdk_threads_enter();
#define GTL gdk_threads_leave();

And then do
GTE
gtk_progress_bar_etc(stuff);
gtk_entry_set_text(stuff);
gtk_status_bar_etc(stuff);
GTL

So it's even less work.  Not perfect, but I bet you faster in execution
time, by the same token.
	-Chris

-- 
lansdoct@cs.alfred.edu
"If I had had more time I would have not written you at all." - Pascal
Linux Programs: http://cs.alfred.edu/~lansdoct/linux/
Linux - Get there. Today.
Evil Overlord Quote of the Day:
150.I will provide funding and research to develop tactical and strategic
weapons covering a full range of needs so my choices are not limited to
"hand to hand combat with swords" and "blow up the planet".