On Thu, Mar 18, 2010 at 4:56 AM, Goswin von Brederlow <[email protected]> wrote: > This is a tricky situation. The md5_update_bigarray() on its own is a > "noalloc" function. But due to the caml_enter_blocking_section() another > thread can alloc and trigger a GC run in parallel. So I guess that makes > the function actually not "noalloc".
Thanks for reporting about your experience! This made me suspect noalloc in a bug of mine, and indeed removing a bunch of noalloc did the trick. Now I'd like to understand. Unlike in your example, global roots were registered for the bigarrays in "my" functions. This should avoid that they are freed when the global lock is released. Still, noalloc seems wrong with those functions. I'm not sure yet which function is problematic in my case, but they all follow the same scheme, see for example <http://savonet.rastageeks.org/browser/trunk/liquidsoap/src/stream/rgb_c.c#L563>. So, is it really forbidden to release the global lock in a noalloc function? Cheers, -- David ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
