On Mon, Feb 07, 2005 at 09:45:44PM +0100, stian@xxxxxxxx wrote: > > Can anyone say with certainty whether g_try_malloc() and g_free() are > > thread-safe? I've spent considerable time searching mailing lists and > > googling and have found only sketchy opinions at best. > > glib itself is thread safe, while the user-side is not. g_malloc and > g_free is thread safe. a GList for instance is not. > > > Historically, I have been wrapping all of my allocations and releases in > > a global mutex, but this seems far from optimal. I assume that these > > functions are implementations of malloc() and free(), but again it seems > > there is no definitive answer to my question. > > malloc and free are not thread-safe unless you define _REENTRANT or such > alike. g_malloc/g_free do not wrap around malloc/free. glib has its own > internal memory management as far as I know. I just looked at glib/gmem.c a bit. As far as I can tell, g_malloc() and g_free() *are* just simple wrappers for malloc() and free(). It's possible to change that with a call to g_mem_set_vtable(), but unless that's happening by default... g_malloc() and g_free(), I'd say, are just as thread safe as malloc() and free(). g_try_malloc() and g_malloc() appear to be more or less identical (if not actually #defined that way). Maybe I'm missing something. What are the threading risks in malloc() and free()? I suppose they both mess with some global pointers and call (...or by calling) brk(). how do you remove the risk? you have to compile libc with _REENTRANT? Also, the g_mem_set_vtable() function does not appear to be thread safe. I imagine that's not an issue in this instance, but makes me question the claim that all of glib is thread safe. - Ben _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
