Changing threading semantics from init early to init before second thread

[Havoc Pennington]

Alexander Larsson wrote:
> Well, it could just be a null function to keep API/ABI. 

That doesn't _strictly_ keep the API, but it does make things still 
compile :-P

>> If we want to preserve the option for people to avoid lock overhead, we 
>> could add dbus_threads_disable() (or not even that - they could just set 
>> thread functions that are no-ops)
> 
> Moving from no threads to thread support is workable, but reinitializing
> dbus (after some use) with a different threading system sounds very
> complex and hard to me.

Not suggesting that at all - dbus_threads_disable() would have to be 
called before you used any thread functions, and would then make those 
functions no-op instead of implicitly initializing the built-in thread 
abstraction. So e.g. dbus-daemon would call this at the start of main().

If a library called this, we would just have to apply cluebat.

Hmm. If we add the change you posted, we should revert John's recent 
patch to allow "fixing up" mutexes if we go from no threads to having 
threads; since that won't happen anymore.

>> The code would read a bit cleaner in my mind if rather than #ifdef'ing 
>> the body of each function, there were essentially one big #ifdef like:
> 
> Sure, the code could be nicer. I'm mainly throwing this out to disprove
> that this is something hard that needs huge library dependencies or
> other things like that.

Good, thanks.

> We could keep the current vtable situation, and add a
> dbus_threads_init_default() call that just uses an internal
> implementation (like your example). I just don't see the need for ever
> using another set of locking primitives though. It only complicates the
> code, and risks adding bugs.

Some possible uses:
  - I think Boehm GC makes you use some special hooks around thread 
calls, don't know the details
  - you can add functions that do debug spew or whatever for locks/unlocks
  - you are on some embedded system using some crazy userspace thread
emulation tricks

All pretty arcane, but not really crazier than allowing people to set 
the dbus_malloc backend...

Havoc