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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
