More heap corruption / allocator lock problems

[Till Straumann]

Hi all.

Paranoia pays off.

Today, (thanks to the paranoia check added to PR#504)
I found one more place where a CORE_mutex (the allocator
lock) is acquired from a dispatching-disabled code section:

The task-variable destructor hook (used e.g. by the rtems_shell
and 'libc userenv')!

Since it is run as part of a user extension's delete
hook/callback, the task variable destructor runs with
dispatching disabled :-(

Two solutions come to my mind:

a) memory that is going to be released by a task-variable
    destructor must be allocated from the workspace

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...

RFC

-- Till