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