Re: How signal-safe is our malloc()?

[christos%astron.com@localhost (Christos Zoulas)]

In article <202511141855.NAA03955%Stone.Rodents-Montreal.ORG@localhost>,
Mouse  <mouse%Rodents-Montreal.ORG@localhost> wrote:
>At work, we have a program that (because of its DOS heritage) does a
>lot of work in signal handlers.
>
>When I first ported it from DOS to NetBSD, I converted interrupt
>handlers into signal handlers.  Then it crashed occasionally.  Digging
>into the crashes, it turned out that it was an Xlib call getting
>interrupted by a signal, with the handler making another Xlib call and
>colliding over some Xlib-internal data structures.
>
>So I opened a second X connection and arranged for the main line to use
>one of them and the "interrupt" (signal-handling) line to use the
>other.  That stabilized it.
>
>Now, for various reasons, they are trying to move it to Linux.  They're
>seeing crashes that look like
>
>	main line ->
>	Xlib (main-line connection) ->
>	malloc-family call ->
>	signal handler ->
>	Xlib (signal-handler connection) ->
>	malloc-family call ->
>	boom
>
>The malloc family in use there is clearly not signal-safe.
>
>This then makes me wonder why we didn't see the same on NetBSD.
>signal(7) says our malloc isn't signal-safe either, but I'm wondering
>whether it actually is signal-safe in 9.1 and signal safety just isn't
>promised, or perhaps it's not signal-safe but the window of risk is
>much smaller, or...what?

I doubt that any implementation of malloc is signal-safe unless it is
intentionally written to be signal safe. 

christos