Changing threading semantics from init early to init before second thread

[John (J5) Palmieri]

I'm looking at the threading implementation and there is this little
codeblock in dbus_threads_init:

if (thread_init_generation != _dbus_current_generation)
    thread_functions.mask = 0; /* allow re-init in new generation */

Along with a warning printed out if you try to init new threads.  Is
this an issue?  I figured it should be whoever initializes first would
win and D-Bus would be happy to use those mutexes everywhere.  I could
see a future where a Qt app utilizes the gtk-file-dialog (perhaps
through portland) and dies miserably because of this codeblock.

The second issue is how to best keep track of the active connections and
servers (servers and connections are the only places we create mutexes).
I figure we keep the list up until we init threads at which point we can
forget the overhead.  The easiest way of accomplishing this in my view
is to add another level of indirection in which we return a pointer to a
mutex pointer in _dbus_mutex_new (and condvar_new) and then keep a list
of these pointers which we update on the first call to threads_init.
This way we don't care where the mutex was created and don't have to
keep track of both the connections and servers.  Any comments?

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
-- 
John (J5) Palmieri <johnp at redhat.com>