Re: [Evolution-hackers] g_mutex, e_mutex and pthread_mutex in camel?!

[Philip Van Hoof <spam pvanhoof be>]

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
> 
-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be