Date: Mon, 6 Nov 2000 09:13:25 -0500 (EST)
From: George Talbot <george@brain.moberg.com>
I respectfully disagree that programs which don't surround some of the
most common system calls with
do
{
rv = __some_system_call__(...);
} while (rv == -1 && errno == EINTR);
are broken. Especially if those programs don't use signals. The problem
that I'm raising is that the default behavior of returning EINTR from
system calls is, in my opinion, an application reliabilty problem. The
specific problem I'm having is that glibc uses signals to implement
multiple threads, and because of the EINTR behavior, expose multithreaded
programs to this behavior that weren't necessarily written to use
signals.
Arguably though the bug is in glibc, in that if it's using signals
behinds the scenes, it should have passed SA_RESTART to sigaction.
However, from a portability point of view, you should *always* surround
certain system calls with while loops, since even if your program
doesn't use signals, if you run that program on a System-V derived Unix
system, and someone types ^Z at the wrong moment, you can also get an
EINTR. Similarly, you should always check the return value from write
and make sure all of what you asked to be written, was actually
written.
What I normally do is have a full_write routine which looks something
like this:
static errcode_t full_write(int fd, void *buf, int count)
{
char *cp = buf;
int left = count, c;
while (left) {
c = write(fd, cp, left);
if (c < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return errno;
}
left -= c;
cp += c;
}
return 0;
}
It's like checking the return value from malloc(). Not everyone does
it, but even if it's not needed 99% of the time, it's a darned good idea
to do that.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Nov 07 2000 - 21:00:19 EST