Changing threading semantics from init early to init before second thread

[Havoc Pennington]

John (J5) Palmieri wrote:
> 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.

It's certainly not OK to change the thread implementation on a later 
call, but ignoring later calls could be OK. I'd feel better if there 
were a way to tell you've been ignored maybe, either a 
dbus_get_threads_initialized() or a return value from dbus_threads_init()

Sometimes it may be important to get the desired thread implementation, 
e.g. if you're trying to set an implementation that does some kind of 
debugging stuff, or the implementation with wacky Boehm GC hooks, or 
whatever.

> 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?

If you track &connection->mutex you'll also have to untrack it if the 
connection is finalized. Something like:
  _dbus_mutex_new_at_location  (DBusMutex **location_p);
  _dbus_mutex_free_at_location (DBusMutex **location_p);

Where the semantic is that the mutex can be replaced on threads init. 
These functions should definitely be private.

It strikes me as somewhat ugly - if e.g. gaim is using libdbus directly 
anyway, why don't they just call dbus_init_threads()?

I wonder if the dummy mutexes should be ints that we increment for lock 
/ decrement for unlock, such that they detect locking bugs and also so 
we can warn if we try to replace a dummy mutex with a real mutex while 
the dummy mutex is "locked" (the recursion case that will result in 
badness). But it would add some gratuitous overhead in the no threads case.

Havoc