Hi Corinna,
Well, this patch turned out to be half-baked. Locking is working correctly
because USE_LOCKS was set to 1 for malloc.cc's compilation. The torture test I
run validated that. OTOH as you said, MSPACES was set 1 for malloc.cc but 0 for
malloc_wrapper.cc. So this patch yields a malloc facility like pre-3.2 but
using internal locking on data structures instead of function-level locking. An
improvement, but not the whole package that I'm attempting to deliver because
there's still thread contention on the internal locks. Properly operating
mspaces should get rid of that or at least lower it significantly.
I appreciate your comments on TLS variables and fork safety. I will investigate
this area further. The mspaces should/will survive a fork but obviously the
threads that created them won't. Memory blocks can be freed by any thread;
there's no need to create threads in the child process just to manage mspaces.
I have more work to do then I'll submit a v2 of the patch.
Thanks & Regards,
..mark
