dbus_g_thread_init()

[Havoc Pennington]

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
    anyway
  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)

Havoc