John (J5) Palmieri
johnp at redhat.com
Wed Sep 13 11:25:04 PDT 2006
On Wed, 2006-09-13 at 14:13 -0400, Havoc Pennington wrote:
> 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)
So removing 3 sounds the most sane. I'll provide a patch for adding the
recursive mutexes, removing the return values and fixing up Alex's code
to fit. There are still some error like the rewritten dbus_threads_init
function that need to be taken out. I am not going to do the
implementation of the the recursive locks just yet. It doesn't need to
be in just yet as long as we have the public interface and I want to get
an RC release out.
John (J5) Palmieri <johnp at redhat.com>
More information about the dbus