More heap corruption / allocator lock problems

[Paul Neelands]

Regarding solution b)

If the special "gc" thread approach is used, how does one insure that it is
run at an appropriate time? i.e. It may not free memory more quickly unless
the "gc" thread is highest priority, which ends up being effectively the
same as the list approach but done via a thread and it's overhead.
Presumably the malloc/free list approach solves this problem and eliminates
the additional interface complexity of solution a)

Paul Neelands

-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
...
> b) free could be enhanced:
>
>    if 'free' is called while _Thread_Dispatch_disable_level > 0,
>    it sends its pointer argument to a special "gc" thread which
>    will eventually execute the real 'free'. The synchronization
>    mechanism *must* be nonblocking, of course, to avoid the
>    same kind of problem...
>
> While I feel that b) is 'hackish', it could certainly provide
> backwards compatibility...

Another simpler approach to this might be to have a list like you suggest
but check that it is non-empty on each malloc or free when
_Thread_Dispatch_disable_level
is == 0.  It doesn't free memory as quickly as a gc thread would but it
would get it into
the heap when it matters.

> RFC
>
> -- Till