Re: strange deadlock ... - FAQ.

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> 	So should I:
> 
> 		a) reccommend people do:
> 
> 		gdk_threads_enter ();
> 		Bonobo_Some_call (foo);
> 		gdk_threads_leave ();
> 
> 		[ in addition to having to do ]
> 
> 		gdk_threads_enter ();
> 		gtk_label_set (GTK_LABEL (l), ...);
> 		gdk_threads_leave ();
> 
> 	Or.
> 
> 		b) Build knowledge of gdk_threads_enter into the otherwise
> 		totaly non-GUI ORB.
> 
> 	Or.
> 
> 		c) Do a violence to glib, and write my own duplicate
> 		polling routine for only the fd's I'm interested in.
> 
> 	Or.
> 
> 		d) Abandon hope in a thread safe ORB.
> 
> 	Or. ? ...
> 

Perhaps another possible option is to have hooks that are called
before/after entering the main loop. a) is simply pushing b) onto
other people, and b) clearly sucks.

Yet another option would be to use threads yourself, instead of the
main loop. So ORBit would always be multithreaded.

However I think c) may be right.  To me c) should be resolved by
deciding what behavior you want:

 1)   You really want any and all main loop event sources to 
      run. You do not want to lock up the application.

 2)   You want to block the entire application until you hear
      back from your remote CORBA server.

While I was eventually told that ORBit did 1), my expectation when I
started using ORBit was certainly 2), that's why I asked earlier why
ORBit even does 1). The reentrancy problems of 1) seem to be
intractable, and I don't understand why ORBit does this.

Havoc