[PATCH] Cygwin: malloc tune-up

[Corinna Vinschen]

Hi Mark,

On Aug 25 00:29, Mark Geisert wrote:
> 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 was not worried about the malloced spaces themselves, but about the
TLS pointer of the thread calling fork().  The TLS pointer itself
(the one returned by TlsGetValue) is not propagated to the child process.
Therefore, this pointer is wrong in the child.  If that's not a problem,
fine.  But if it has to be preserved over fork, then the cygtls area
is definitely the way to propagate thread-specific info via fork.


Corinna