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

Michael Deutschmann michael at talamasca.ocis.net
Wed Mar 14 13:13:03 UTC 2012


On Tue, 13 Mar 2012, Rich Felker wrote:
> I would consider this a flaw in the standard since it largely prevents
> using EINTR in any useful way.

EINTR wasn't invented to be useful, it was invented because it was easier
to implement in pre-sigaction() SysV kernels than SA_RESTART semantics.
Known as the "PCLSR problem", it is an often cited example of the "Worse
is Better" design philosophy at work.

> I was assuming the old standard idiom of installing a do-nothing signal
> handler (without SA_RESTART) for SIGALRM so that fgets would return with
> an error and the program could proceed.

That's a broken idiom, since if the signal should arrive just one opcode
before the read syscall begins, it will be ignored.  If you need reliable
signal interruption, you must use sigsuspend() or longjmp out of the
handler.

It's also the only possible use of a cleared SA_RESTART, so it's crazy not
to set the flag all the time.  That we have a SA_RESTART flag at all, is
just a measure so that old SysV programs abusing the design flaw break
occasionally instead of often.

One historical note:

Circa 2000, I was actively reading glibc's bugs list and trying to help
out.  Someone posted a bug report ("libc/1174" in the old GNATS system)
citing this very issue, and I suggested a patch to restart after EINTR
within stdio -- since any deliberate use of interruption would involve a
race condition.

Ulrich Drepper denied it, on the grounds that:
) But this is not correct.  You must be able to set an alarm() and
) terminate a blocked fwrite() code.  This is required and tested by all
) kinds of standard test suites.

Although that exchange eventually had one productive result -- the node
"Error Recovery" in the glibc manual, which I basically wrote.

Sounds like in the intervening decade, glibc may have come around to my
thinking....

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


More information about the uClibc mailing list