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

Laurent Bercot ska-dietlibc at skarnet.org
Tue Mar 13 09:30:10 UTC 2012


> Note that I'm claiming the whole "safe_read"/"safe_write" idiom is
> wrong, and a throwback to the pre-sigaction SysV era when signal() was
> the only way to install a signal handler and it gave you
> non-restarting semantics. The idea of an interrupting signal, when set
> intentionally by a modern application using sigaction, is that EINTR
> should be treated as a (usually permanent/unrecoverable) failure on
> blocked in-progress IO operations.

 Hi Rich,

 I'm not pronouncing on stdio, since stdio doesn't really mix with
asynchronous event loops anyway; but in an event-driven program that
reacts to signals as well as fd events or timeouts, signals can
arrive at any time and should be handled by the application at the
same level as any other event, in a normal context, *not* right when
they arrive in an interrupt context. (Think pselect(), or the self-pipe
trick.)
 In this case, it is absolutely necessary to protect every read() and
write() operation, as well as any interruptible system call, against
EINTR, because EINTR is not reporting a failure, it is only reporting
the arrival of a signal at an inconvenient time.
 This protection can be done at the user level, but there is nothing wrong
with safe_read and safe_write functions. My skalibs library provides
safe wrappers for most interruptible system calls, so the program flow
doesn't get disturbed by incoming signals; signals will get handled
in their own time anyway.
 Why not simply let the user set SA_RESTART in the sigaction() call?
see http://www.skarnet.org/software/skalibs/libstddjb/safewrappers.html

 You are right about EAGAIN though. The point of EAGAIN is for a
non-blocking system call to return immediately instead of blocking,
and it should never be hidden to the user.

-- 
 Laurent


More information about the uClibc mailing list