Re: strange deadlock ... - GMainContexts

[Sebastian Wilhelmi <wilhelmi ira uka de>]

> > Actually, the recent changes to GMainContext were done primarily so
> > Sebastian could do exactly this in ORBitMT.
> 
>         Ahh, I read it again - I assume then that Sebastian sets up his
> own GMainContext for the CORBA descriptors ?, in which case how does he
> integrate with a Gtk+ program ?
> 
>         Is it possible to have ( in the default case ) multiple
> GMainContexts [ the default Gtk+ one, and the CORBA one ] blocking
> waiting for input - and reserve just blocking on the CORBA Context for
> these re-enterancy cases ?. Clearly it is not desirable to have a
> little loop belting round polling two contexts in a non-blocking
> fashion.

My current plan is to add all CORBA sources to both the default context and my
own private ORBit-mt context and whenever I sent out a request I wait through
looping this private context. This prevents GTK+ reentrancy. But the normal
main loop still recognizes CORBA calls
 
But anyway I think holding the GTK lock over the call to any main context
looping is not going to work.

Another simple solution would be to use recursive locks for gtk_threads_leave
and _enter. They are not much more expensive (nested calls indeed are
considerably faster than normal calls) and they have those nifty functions
g_static_rec_mutex_lock_full and g_static_rec_mutex_unlock_full to make it
possible to release them completely before e.g. a main loop call.

  depth = g_static_rec_mutex_unlock_full (mutex);
  g_main_loop_run(loop)
  g_static_rec_mutex_lock_full (mutex, depth);

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi