Re: Is malloc signal-"tolerant"?

[Stefan Hoffmeister]

: On 23 Dec 2001 00:52:21 -0000, Wolfram Gloger wrote:

>Signal-safe spinlocks are an alternative.  

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

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?

The only thing that I *could* imagine *might* be working for a
"signal-tolerant" malloc is an atomic (CPU) instruction like XCHG that
flips the switch (a pointer, presumably) between an updated copy of a
data structure and its "old" modified version. That switch would have to
be the one and only entry point and point of "failure" for memory
management.

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.

Note, though, that I haven't ever written a general malloc, either :->

>Blocking a signal in every malloc() would be _way_ too costly.

Yep, I realise that.

[I'll try to play with the new malloc over the next few days - but
unfortunately this new malloc won't help me in the near to medium term
future, given the number of existing systems out there with glibc
versions ranging from 2.1.3 to 2.2.4]