Changing threading semantics from init early to init before second thread

Havoc Pennington hp at redhat.com
Thu Aug 24 08:38:19 PDT 2006


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.

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?

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)

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:

#ifdef WIN
#include <windows.h>
default_mutex_new() {
}
default_mutex_lock() {
}
...
#else
#include <pthread.h>
default_mutex_new() {
}
default_mutex_lock() {
}
...
#endif

static DBusThreadFuncs default_threads = { default_mutex_new, 
default_mutex_lock };

static void dbus_threads_init_default(void)
{
	dbus_threads_init(&default_threads);
}

Havoc



More information about the dbus mailing list