Re: callbacks and locking

[Owen Taylor <otaylor redhat com>]

hugo hallqvist <hugha495 student liu se> writes:

> ons 2002-10-23 klockan 20.50 skrev neh attbi com:

> > I tried this same thing recently, and for the same reasons.  I
> > eventually had one problem I could not quite figure out (albeit I
> > have a few things left to try).  My problem was that my app was
> > not processing all of the expose events to draw and redraw widgets
> > properly.  If you get your app to work, let us know how.  It would
> > prevent me from having to move all of my gtk calls to the main
> > thread . . . Thanks.
>
> Hmm, I solved at least my problem now. I switched to Gtk2. It works
> beautifully now with regards to releasing gdk-lock inside a callback. I
> don't really know what the reason for this not being able to work in
> Gtk1.2, if it's a bug in Gtk1.2 or if the locking/thread-awareness in
> Gtk2 has improved so much. 
>
> The strange thing is that I did not change one line of code! I just
> changed the Makefile and it worked beautifully. Of course there is some
> porting left to do for example chars to UTF8. But as of now I think I
> will go with this option and require users to upgrade to Gtk2, rather
> then to mess with something that is obviously broken (or at least it is
> from my point of view).

Please note that there was one important change in how threading works
in GTK+-2.0 - you have to call gdk_threads_init() as well as
g_thread_init(). If didn't change any code and aren't calling
gdk_threads_init(), then you may well have solved your hang simply
because you aren't locking at all any more, and are just getting
lucky.

Releasing the lock inside a callback should work generally fine ... 
GTK+ already needs to be very robust against reentrancy across 
signal callbacks because there is no real constraint in what an
application can do in a signal callback.

Regards,
                                        Owen