Re: System calls interrupted by signals - or not

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <address@hidden> writes:

>>This can happen if interrupted by a signal, 
>
> If only BSD-style signals (SA_RESTART) are used, as is very likely, this
> should not happen.

Guile is a library meant for use within existing applications, and
therefore needs to be able to cope with whatever signal handling policy
those applications have chosen.  We certainly cannot assume that all
kinds of signals will be configured for SA_RESTART.

> It only happens with old "PC-losering" style signal handlers - which even
> signal(2) doesn't install anymore (and I know of no reason why anyone
> should ever use those).

Although SA_RESTART is more convenient, less error prone, and arguably
the sensible default, it is also strictly less powerful than what you
can do without SA_RESTART.  There are cases where you may want the
ability to interrupt a system call without killing the thread.  Suppose
you are waiting for a large I/O operation to complete over a slow
network or device.  Signals are the only way I know of in POSIX to
interrupt a system call, but it can only be done if there's at least one
kind of signal that's not configured for SA_RESTART.

At least that's my understanding.  Please correct me if I'm wrong.

Note that EINTR is the default behavior in GNU libc when using the
advanced signal handling interfaces:

<https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html>

  "When you don’t specify with ‘sigaction’ or ‘siginterrupt’ what a
   particular handler should do, it uses a default choice.  The default
   choice in the GNU C Library is to make primitives fail with ‘EINTR’."

      Mark