> 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
