Havoc Pennington hp at redhat.com
Wed Sep 13 11:13:24 PDT 2006

John (J5) Palmieri wrote:
> We still need it for specialized types.  There have been many a
> scratched head on why D-Bus GLib calls weren't working that finally came
> down to types weren't initialized because dbus_g_bus_get wasn't called
> yet.  It is easier to spot that someone didn't call the init function.

Just a bug though - either all the entry points should call 
g_type_init() or none of them. It isn't really all functions since most 
functions are methods on objects, you can know one of those objects has 
been created, so you only have to g_type_init() in the object 
constructors and you know you have always done it before the methods on 
the objects are called.

But people using glib should expect to have to call g_type_init, if they 
aren't confused by dbus they will be confused by some other library that 
requires it. So I'm not sure calling g_type_init() automagically is 
worthwhile at all.

I did not agree with g_type_init() existing, but since it does, it's 
just a property of glib. It could be fixed in glib by auto-calling it in 
the type registration functions, but we should not try to fix it outside 
glib really imo. We should _definitely_ not spread the disease by having 
our own dbus_init function, we should either leave the problem as "you 
must g_type_init" or we should call g_type_init for you.

> In any case if use Alex's patch, make dbus_threads_init a noop and turn
> on threading by default means I can take the recursive mutex TODO off
> (since it is internal), I'll be happy with that.

Alex's latest patch doesn't do this though does it, it just adds a 
dbus_threads_init_default() that you can use if not using a binding.

There are several possible threads changes that have come up:
  1 add recursive mutexes to thread funcs, or make existing
    mutexes have to be recursive
  2 remove return value from lock/unlock since it is not honored
  3 change the default - init threads unless they get explicitly disabled
  4 provide a default/builtin thread funcs implementation

I guess it might be good to right away explicitly put each of those on 
the 1.0 list or remove them from the 1.0 list.

To avoid breaking API, I might suggest that for 1.0 do all of them except 3.

You could do 1 and 2 at the same time by deprecating the current mutex 
functions in the thread funcs vtable and adding new recursive mutex 
funcs without the return value. Then, implement the internally-used lock 
function as:
  - if recursive mutex func present, never use the nonrecursive lock
    functions, so new apps need not provide the nonrecursive ones
  - if no recursive mutex func, fall back to the old nonrecursive ones
    so old apps keep working (but still have the deadlock issue as they
    do today)


More information about the dbus mailing list