dbus_g_thread_init()

[John (J5) Palmieri]

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

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>