Messages in this thread |  | | From | devnull@spaans ... | Date | Mon, 6 Nov 2000 11:55:05 -0500 | Subject | Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer... |
| |
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/
|  |