Changing threading semantics from init early to init before second thread

[Alexander Larsson]

On Thu, 2006-08-24 at 11:38 -0400, Havoc Pennington wrote:
> Alexander Larsson wrote:
> > 
> > Here is an implementation i hacked up based lightly on the win32 glib
> > thread implementation. Its lightly tested, just passed make check on
> > unix/win32.
> > 
> 
> Cool, thanks. I think it'd be better to avoid breaking the API; while I 
> agree being able to replace the thread functions isn't 
> earth-shatteringly useful, it is in the API already and doesn't really 
> hurt anything.

Well, it could just be a null function to keep API/ABI. 

> For the case where we use our own threads, I'd rather avoid init() 
> functions with no arguments; those should always be possible to call 
> automatically the first time they are needed. In this case for example 
> auto-initializing threads in mutex_new and condvar_new would likely be 
> good enough?

Sure, if we want to always use threads that would make a bunch of code a
lot simpler. It will cause e.g. the dbus daemon to always use threading
code though, which is completely unnecessary given that the daemon is
single threaded and might cause performance issues.

> 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. You need to keep track of all existing mutexes
and their state so you can convert them when threads_init() is called.
And its all totally useless anyway, the native dbus mutexes will work as
well as whatever functions you manually set.

dbus_threads_disable() sounds nasty. If any library or app ever calls
this they need to be 100% sure that some code they link to doesn't use
dbus and rely on the thread support being on. This can't be guaranteed
of course, and will lead to strange bugs.

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

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.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a Nobel prize-winning Republican cowboy She's a tortured insomniac 
schoolgirl with her own daytime radio talk show. They fight crime!