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
- 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
More information about the dbus