> "THIS CHANGE CAUSED PROBLEMS FOR SOME APPLICATION CODE."
>
> _Which_ applications?
>
> _Why_ did they have a problem? Was this due to a bug or were they
> designed to do stuff this way?
I, for one, have an app that relies on syscalls not being restarted:
app goes into a blocking read on a socket
signal interrupts blocking read
signal handler sets a global flag
read returns interrupted
flag is checked - action may be taken
Now, this could be redone to use a select() with a small timeout (busy
loop), but the blocking read is more convenient, as there may be many
instances of this app running.
> How hard would it be to change these programs to use
> sigaction() to enable the EINTR behavior? We've got the source
Actually, you already have to specifically call sigaction to get the EINTR
behavior - glibc signal() (obsolete) sets SA_RESTART by default. What this
suggests is that something in pthreads is unsetting SA_RESTART, or calling
sigaction without it. grep?
> Moreover, I'm willing to bet money that a large percentage of user-land
> programmers aren't even _aware_ of the EINTR issue. The Netscape people
> certainly weren't for Netscape 4.x. Don't know if the Mozilla people are.
Then they have never read a decent UNIX programming text. Page 275 of
"Advanced Programming in the UNIX Environment", W. Richard Stevens (a de
facto standard for texts in this area). An entire section of the chapter
is spent on interrupted syscalls. If I were the manager of a team of
people who didn't handle it, I'd be very disappointed.
-
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:20 EST