Re: Is malloc signal-"tolerant"?

[Wolfram Gloger]

> I am not certain whether I understand this comment. Asynchronous signals
> will interrupt any user code, be it a spinlock or not?

Sure.  But the spinlock provides an atomic, signal-safe means of
deciding whether a malloc arena is in use or not.  ptmalloc can
generate new arenas if all previous ones are in use.

> The general flow of events to breakage in a single-threaded scenario
> should be
> 
>   * enter malloc
>     + bring data structures into a transient state
> 
>   * get signal
>   * enter signal handler
>   * longjmp out of signal handler
> 
>   * enter malloc
>   // data structures are still in the transient state
>   // booom.
> 
> and whether modifications to the data structures are protected by a
> signal-safe spinlock (which won't block the signal) or not shouldn't
> matter?

Yes it does.  With them, the following should be possible and safe:

static void *ptr = 0;

void signal_handler(int sig)
{
  void* ptr = malloc(sz); /* not portable! */
  /* ptr will be from a new arena if the main arena has been in use
     while the signal occured */
  ..
#if FREE_INSIDE_HANDLER
  free(ptr);
#endif
}

int main(...)
{
  /* signal can occur anywhere in the following */
  ...
  p = malloc();
  ...
  free(p);
#if !FREE_INSIDE_HANDLER
  free(ptr);
#endif
  ..
}

for any value of FREE_INSIDE_HANDLER.  This could be useful.

Your original example will "work", too, although with a memory leak.
What _still_ won't work is, if your example was modified to eg. later
free() a pointer that was allocated _before_ the signal interruption
-- that would hang.  I.e. once you have interrupted malloc/free and
longjmp()ed somewhere, you can only alloc/free _new_ memory.

> I doubt that given these requirements it would be possible to write an
> efficient malloc that would still be fast :-) Oh, and the malloc would
> still leak memory whenever it gets a signal at the wrong time.

Indeed, full interoperability with signals can not be a goal.

Regards,
Wolfram.