Changing threading semantics from init early to init before second thread

[John (J5) Palmieri]

On Mon, 2006-08-14 at 11:42 -0400, Havoc Pennington wrote:
> John (J5) Palmieri wrote:
> > With Gnome-VFS (and mozilla) being an issue these days in terms of
> > making non-threaded apps threaded and killing D-Bus in the process would
> > it be possible to fix the internals to be able to init before the second
> > thread is started?  In this scenario we keep track of all the
> > connections, when dbus_threads_init is called it goes to those
> > connections and updates all the dummy mutex's (asserting on mutex's
> > that != the dummy mutex || != the new mutex just for sanity checks).
> > Since we are still in the main thread there is no race condition at the
> > point dbus_threads_init is called.  This would allow Gnome-VFS to init
> > threads late in the game without the app having to know.
> > 
> 
> Do you think it's worth it or will people just fix their apps?
> 
> There would be some weirdness still if we did this... for example, if 
> you initialized threads while inside a dbus callback, stuff could break 
> in all sorts of crazy ways.
> 
> Havoc

I would say calling it in a callback is an issue we can place squarely
in the apps corner.  GLib has the same issue and documents it:


Note
g_thread_init() must not be called directly or indirectly as a callback
from GLib. Also no mutexes may be currently locked, while calling
g_thread_init().


And while I contend this issue is not a D-Bus bug it would be a
convenience for us to make this change provided it doesn't overly
complicate the code.  Already we are getting pushback from the Gaim
developers since all they do is include the file chooser which in turn
loads the threaded Gnome-VFS library as a plugin when you are in a Gnome
env.    

-- 
John (J5) Palmieri <johnp at redhat.com>