[PATCH] prevent retries on fclose/fflush after write errors

Michael Deutschmann michael at talamasca.ocis.net
Sat Mar 24 00:01:42 UTC 2012

On Wed, 14 Mar 2012, Rich Felker wrote:
> It was cited in "Worse is Better", yes, but I don't entirely believe
> the anecdote. SA_RESTART semantics are no harder to implement; it's
> just a matter of whether you save the address of the syscall
> instruction or the instruction immediately after it when invoking a
> signal handler.

Usually the address instruction immediately after will already be on the
stack, or some sort of task structure, as part of the normal syscall
process that would be followed in the absence of signals.

Now, adjusting the saved instruction pointer would not be hard in machine
code.  Generally, the saved user IP is sitting somewhere in the kernel
stack a predictable distance above the return address for the kernel
function implementing the call, like a hidden extra argument.  But access
to such context isn't something C compilers are good at, and the stack
offset and syscall opcode length must be customized for each processor

The ancient worse-is-better Unix programmers probably decided to just
foreclose on syscalls doing anything to the userspace registers (aside
from the one used to return results).  This made the assembly glue
joining a CPU-agnostic C kernel to a specific machine as simple as
possible, and made EINTR the only acceptable way.

> It can be solved (albeit in an ugly way) by having the signal handler
> re-arm the alarm with exponential falloff in delay (in case the system
> is so loaded that it can't return from the signal handler before
> another timer expiration happens).

Yuck.  That's a lousy quality of implemantion, and isn't even adequate
for probing whether a system implements EINTR.

> Even if your approach is preferable to users, I don't think it's
> conformant, since POSIX specifies the EINTR error for fgetc. Since all

That may be just tolerance for a lazy stdio that doesn't work any harder
than it needs to.  Certainly no one disputes a stdio is *allowed* to treat
EINTR same as EIO.  The question is whether it *must*.

---- Michael Deutschmann <michael at talamasca.ocis.net>

More information about the uClibc mailing list