Also note that your termination code would need to consider, in a similar fashion, how to terminate gracefully: if a thread is in the middle of creating a temporary file, it shouldn’t be shot-dead at that exact moment.

Edit: Unfortunately, my original post appears to be wrong, see below, and I can’t strike it out because I don’t own it.

I did “read it carefully,” thank you all very much. I intended to use the term, “thread-safe,” loosely in this particular case, and in fact I did it inappropriately.

The race that I hypothesize, does not concern resources being shared by threads in a single process-context, but rather, the resources that are being shared by all of the processes in the login-shell environment. A statement as simple as $ENV{'FOOBAR'} = $ENV{'FOOBAR'} + 1; would exhibit this sort of race-condition conflict.

It could also be that you should not exit()within the signal handler, but instead should set a flag which causes the main loop of the child process to end as-soon as-possible. When this is done, then, no matter what the process was doing at the unpredictable instant in which the termination-signal arrived, you know that it will end at a predictable point and in a predictable state ... real soon now, but not at this very instant.

Looking, now, more closely than I did before at the relevant perlguts, I see that JUMPENV_PUSH has to do with longjmp() state-saving. Maybe there’s a hole there somewhere, and if so your task is to avoid it not to fix it. By delaying the actual terminate to “real soon now” instead of “right now,” you’d avoid such a hole.

The only immediate “response to” the signal is to set a flag which indicates that a signal has been received. The child’s processing-loop frequently tests this flag at strategic places, and busts-out of the processing loop gracefully. The arrival of a signal should also knock the process out of various kinds of voluntary sleep, so that it will always be responded-to. But it no longer matters precisely what the process was doing at the precise instant that the telephone rings.

The parent-process should also explicitly wait-for children to terminate, before finally exiting itself, and before tearing-down any data structures that the children might depend on. The second most-common place where applications sporadically fail, is when they are ending, because the parent jerks the rug out from under the children “sometimes.”

It could also be that you should not exit() within the signal handler, but instead should set a flag which causes the main loop of the child process to end as-soon as-possible.

When this is done, then, no matter what the process was doing at the unpredictable instant in which the termination-signal arrived, you know that it will end at a predictable point and in a predictable state

Yes, that's often good idea to just set flag in signal handler.

However, I was hoping that Perl is kinda high-level language, so there can be nothing unpredictible in termination in random point of program (with Safe-signals).

Another problem, that my child processes have several possible places where they can spend significant amount of time. Inserting check for flag in all of those places is inconvenient.