But PERL_SIGNALS does not affect the operating system in any way. Linux deliveres SIGALRM as it would for any other program. That means that the flock() system call (deep inside the perl flock() function) will be interrupted and will return EINTR immediately after the signal handler (deep inside the perl executable, not $SIG{'ALRM'}) has returned.

Sorry, but I think you're wrong. The signal is "delivered" to the process, but the process can block, or ignore it or (as perl since 5.8.1) defer it.

We are talking about a signal that has a custom signal handler set up. Blocking or ignoring is completely irrelevant for this discussion. But yes, the kernel runs through some code that decides if how the signal is handled. Options are:

• Call a user mode function (signal handler), this is what happens here.
• Put it into a queue (blocked signal, becomes pending signal)
• Ignore it (ignored signals)
• Call the default handler inside the kernel. What happens here depends on the actual signal:
  • Terminate the process (SIGHUP, SIGINT, SIGTERM, SIGALRM, and others)
  • Ignore the signal (SIGCHLD, SIGURG, SIGWINCH, and others)
  • Terminate the process and dump core (SIGQUIT, SIGILL, SIGFPE, SIGBUS, and others)
  • Stop the process (SIGSTOP, SIGTSTP and others)
  • Continue the process if it currently stopped (SIGCONT)

This happens during delivery, before user mode code is called.

For some signals (SIGKILL and SIGSTOP), the only option is the default handler. The kernel will enforce that handler, even if you have managed to set up blocking, ignoring, or a signal handler for those signals.

What you call "defer" is not a special option for signal handling, but just a user mode signal handler that only sets a flag, combined with code to poll that flag later. This happens completely in user mode, inside the perl executable.

But, this is way outside my knowledge base

Yes, it seems so.

Alexander