dbus_g_thread_init()

[John (J5) Palmieri]

Here is the patch.  I committed Alex's patch as I did not see his
followup which contained the correct fixes. If it is good I want to do
an RC release tonight.

On Wed, 2006-09-13 at 16:30 -0400, Havoc Pennington wrote:
> 
> 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
-- 
John (J5) Palmieri <johnp at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus-recursive-threads.patch
Type: text/x-patch
Size: 9953 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060913/6c7475a1/dbus-recursive-threads.bin