dbus_g_thread_init()

[Havoc Pennington]

John (J5) Palmieri wrote:
> On Wed, 2006-09-13 at 16:09 -0400, John (J5) Palmieri wrote:
>> On Wed, 2006-09-13 at 14:34 -0400, Havoc Pennington wrote:
>>> John (J5) Palmieri wrote:
>>>> So removing 3 sounds the most sane.  
>>> There's nothing to remove right - it's not in cvs, alex's latest patch 
>>> is only #4 without #3 iirc.
>>>
>>> If you combine 1 and 2 (add recursive mutex funcs without a return 
>>> value, and leave nonrecursive mutex funcs unmodified) then there's just 
>>> a small patch to add four new funcs (recursive new/free/lock/unlock), 
>>> and prefer them if they are present (make _dbus_mutex_* choose the 
>>> recursive versions if possible).
>> Big question I just ran into while implementing this is why do we need
>> both if we are not going to use nonrecursive mutex's if we have the
>> recursive ones?  Wouldn't the thread implementation just pass in
>> recursive mutex functions in place of the non-recursive ones? Or are
>> there cases where we want to use nonrecursive mutex's even if we have
>> recursive mutex's?
> 
> Nevermind.  Function signatures would cause errors. 
> 

It's just a compatibility issue. I think it could be OK to just remove 
the return value from the existing mutex funcs, it might only cause 
compiler warnings and not an ABI change. But I'm not sure. It could 
cause compiler errors also.

Havoc