User-space interrupts

Posted Oct 12, 2021 23:45 UTC (Tue) by neilbrown (subscriber, #359)
In reply to: User-space interrupts by anton
Parent article: User-space interrupts

Your description of EINTR roughly matches my understanding of ERESTART.

In many cases a syscall that returns EINTR should *not* be restarted. A blocking read is an obvious case. The application should be given the opportunity to choose whether to restart.
It *might* be possible for a platform (such as python) to require that syscalls which cannot be restarted don't get used. e.g. reads must be non-blocking. But that is a higher-level design choice than the libc syscall wrapper.

User-space interrupts

Posted Oct 13, 2021 6:37 UTC (Wed) by anton (subscriber, #25547) [Link] (6 responses)

Looking at the wrapper of read() (one of the system calls that , it does not handle ERESTART, and ERESTART is not documented as an error returned from read(), while EINTR is.

Why do you think that a blocking read() should not just continue (by restarting the system call) if the signal handler just returns after doing whatever it was doing? Why should every user of read() have to deal with EINTR?

User-space interrupts

Posted Oct 13, 2021 13:19 UTC (Wed) by madscientist (subscriber, #16861) [Link]

That doesn't work: the user needs to deal with the signal that was received, and since signal handlers are so restricted it usually needs to happen in "normal context" not inside the handler. And after dealing with it, they might or might not want to restart the read(). Perhaps the program got a SIGCHLD and before we restart reading we need to deal with our dead child process. Or maybe the interrupt was SIGINT and we want to shut down the process in a reliable way after doing cleanup, so the signal handler set a flag but now we definitely don't want to re-enter the read() at all.

User-space interrupts

Posted Oct 13, 2021 22:47 UTC (Wed) by neilbrown (subscriber, #359) [Link] (4 responses)

> Why should every user of read() have to deal with EINTR?

It's not "every user of read()", but only every user of read() reading from a file descriptor on which reads can block.
That does NOT include regular files - mainly char devices and sockets.
When you read from something that can block, you usually want more than you can be sure of getting in a single read. You'll usually need to be prepared to read some more anyway (not always, but often).
So you need to be prepared for a short read, and handling EINTR as well is not a whole lot more effort.

You certainly *could* have a platform where read() always retries EINTR, and signal handlers have to use longjmp if they want to abort a system call. But I don't think that would be *clearly* better than the current situation. Maybe marginally better - I don't know.

User-space interrupts

Posted Oct 13, 2021 23:23 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (1 responses)

> But I don't think that would be *clearly* better than the current situation. Maybe marginally better - I don't know.

When an idea involves normalizing the use of longjmp() in code written by mere mortals, that creates in my mind the (theoretically, but probably not practically, rebuttable) presumption that the idea is absolutely terrible.

User-space interrupts

Posted Oct 14, 2021 17:18 UTC (Thu) by anton (subscriber, #25547) [Link]

I found writing a signal handler more of a challenge than performing the longjmp() (and I don't remember ever having a bug due to the longjmp()). The problem is that asynchronous signals can be invoked anywhere, including in the middle of updating some data structure, so you have a chance of corrupting the data structure if you longjmp() out of a signal handler for an asynchronous signal.

User-space interrupts

Posted Oct 14, 2021 17:13 UTC (Thu) by anton (subscriber, #25547) [Link] (1 responses)

Unix has the very good idea that everything is a file. One of the benefits is that you can write some general routine on top of the system calls, and it is useful for all kinds of things. This admittedly does not work all the time, but we should strive for it.

In the present case, requiring the general routine to know whether it is used on a file that can result in EINTR, and how to behave in that case (which is very likely application-dependent) breaks modularity.

The application and its signal handler know how to deal with the situation, and the longjmp() approach is a good one in that sense. Of course, leaving an asynchronous signal with longjmp() has its dangers, but that's still the way we chose in Gforth (where asynchronous signals are rare).

User-space interrupts

Posted Oct 14, 2021 19:51 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

IMHO the unnecessary complication here is that "regular files" are treated specially. When your "regular file" could be backed by a network filesystem, FUSE, NBD, etc. it really ought to be considered more like a socket, subject to potential short reads and returning EINTR on signals whether or not any data has been read.

Users generally expect to be able to use sockets and pipes in place of regular files, e.g. using process substitution in Bash or named FIFOs or Unix-domain sockets in the filesystem, or arbitrary paths under /proc/$PID/fd/. Unless there is a good reason to require capabilities specific to regular files, for example lseek() or mmap()—or the application creates the file itself with O_EXCL—then applications ought to expect that read() and write() may process less data than requested even if the normal case involves regular files.

As for the longjmp() approach, that only works because the kernel backs out of the blocking call before invoking the signal handler. (A longjmp() call from a signal handler can't perform a non-local return out of arbitrary *kernel* stack frames.) At that point it's mostly a matter of policy whether the kernel restarts the system call after the handler returns or just returns EINTR to the caller—either always restarting or always returning EINTR would not simplify the kernel signficantly—and in general matters of policy are best left to application or library code rather than the kernel. Wrapping every non-interruptable read() in a loop to restart it until you get all the data you wanted is not substantially more code, or more *complex* code, than wrapping every read() which you might want to interrupt in a call to setjmp() and communicating that fact to the signal handler so it can decide whether to call longjmp().

POSIX also has these caveats regarding longjmp() from a signal handler:

> It is recommended that applications do not call longjmp() or siglongjmp() from signal handlers. To avoid undefined behavior when calling these functions from a signal handler, the application needs to ensure one of the following two things: … After the call to longjmp() or siglongjmp() the process only calls async-signal-safe functions and does not return from the initial call to main(). … Any signal whose handler calls longjmp() or siglongjmp() is blocked during *every* call to a non-async-signal-safe function, and no such calls are made after returning from the initial call to main().

It would be difficult to guarantee either of these restrictions are met in a complex application with many library dependencies. For example, if you return from a signal handler with longjmp() and then call printf() without masking every signal whose handler could call longjmp() then you've already broken both of those rules and invoked undefined behavior.