Re: g_mutex, e_mutex and pthread_mutex in camel?!

A cursory glance at EMutex suggests that GStaticRecMutex and EMutex
(recursive type) behave slightly differently which may cause problems...

Jeff

On Mon, 2006-03-13 at 14:57 +0100, Philip Van Hoof wrote:
> On Mon, 2006-03-13 at 12:54 +0100, Philip Van Hoof wrote:
> 
> > Is there a reason why g_mutex, e_mutex and pthread_mutex are used in a
> > mixed may on libcamel?
> 
> Note that the GStaticRecMutex can also be used as non-static:
> 
> http://mail.gnome.org/archives/gtk-list/2002-January/msg00045.html
> 
> It looks like recursive non-static mutexes is the only reason why EMutex
> is still in place.
> 
> I'm willing to replace all those remaining mutexes to GStaticRecMutex if
> such a patch would eventually be applied. So are there any remaining
> issues with the GLib GThread mutex implementations?
> 
> I'd like to do this to further decoupling camel from libedataserver.
> 
> 
> > Anyway, I'm getting this segmentation fault on the
> > CAMEL_DATA_WRAPPER_UNLOCK call in camel-data-wrapper.c 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1226287424 (LWP 16199)]
> > 0x00001098 in ?? ()
> > (gdb) bt
> > #0  0x00001098 in ?? ()
> > #1  0x00000012 in ?? ()
> > #2  0x00000f40 in ?? ()
> > #3  0xb7a3d653 in write_to_stream (data_wrapper=0x8067aa8,
> > stream=0x8067c58) at camel-data-wrapper.c:149
> > #4  0xb7a3d6d7 in camel_data_wrapper_write_to_stream
> > (data_wrapper=0x8067aa8, stream=0x8067a38) at camel-data-wrapper.c:175
> > 
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[email protected]  - www.novell.com