Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...
Considering that the threading library for Linux uses signals to make it work, would it be possible to change the Linux kernel to operate the way BSD does--instead of returning EINTR, just restart the interrupted primitive?
For example, if I'm using read(2) to read data from a file descriptor, and a signal happens, the signal handler runs, and read(2) returns EINTR after the system call finishes. Then I'm supposed to catch this and re-try the system call.
I assume that this is true for _any_ system call which makes the process block, right?
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do what BSD does: re-start the interrupted call?
Please? If this is something that would be acceptable for integration into a mainline kernel, I would do my best to help with a patch.
If I'm wrong about this, please enlighten me. Also, please cc: me off the list, as I don't get the list directly.
Thank you for your consideration.
--
George T. Talbot
<george at moberg dot com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · [email protected] writes:
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
Signature · 7 lines
---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Hello!
Quoted 4 lines
Quoted 2 lines
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: [email protected] In newsgroup: linux.dev.kernel
Quoted 10 lines
Hello!
Quoted 4 lines
Quoted 2 lines
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do what BSD does: re-start the interrupted call?
This is crap. Returning EINTR is necessary for many applications.
Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
signal() is crap... I personally think it was a major lose to have signal() change to BSD behaviour by default (an unexpected change for most applications!!)
For sigaction() you must choose behaviour explicitly anyway, by either specifying or not specifying SA_RESTART.
Applications should use sigaction(). Period. Full stop. signal() is so unpredictable these days as to be practically unusable.
-hpa
Signature · 7 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Ulrich Drepper
Quoted 2 lines · [email protected] writes:
Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do what BSD does: re-start the interrupted call?
Quoted 6 lines
This is crap. Returning EINTR is necessary for many applications.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat--' drepper at redhat.com------------------------
After reading about SA_RESTART, ok. However, couldn't those applications that require it enable this behaviour explicitly?
The problem I'm having right now is with pthread_create() failing because deep somewhere in either the kernel or glibc, nanosleep() returns EINTR during said pthread_create() and pthread_create() fails.
I've got a multithreaded program written using gcc (2.95.2) and glibc (2.1.3), and it's talking to a natively threaded Java program (tried both Sun & Blackdown ports, both 1.2.2 and 1.3) on a 2.2.17 kernel. The C program is listening for incoming socket connections, and the Java program is hammering on it with many parallel connect() calls. After a short, a bit random interval, pthread_create() will fail in either my program, or deep in the Java VM. I assume that the Java VM is using pthread_create().
I don't mean to sound like a psycho on this, but I can't see why SA_RESTART isn't the default behavior. Maybe I'm missing something somewhere.
--
George T. Talbot
<george at moberg dot com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · On Fri, 3 Nov 2000 [email protected] wrote:
I don't mean this to sound like a rant. It's just that I can't possibly ascertain why someone in their right mind would want any behaviour different than
SA_RESTART.
study apache 1.3's child_main code, you'll see an example of EINTR in use. it's used to get out of accept() -- most specifically when the child needs to die off (because the parent has determined that there's either too many children, or because a shutdown/restart is occuring).
apache 1.3's BUFF code also uses EINTR for timeouts.
i eliminated signals in the 2.0 design... so it doesn't use EINTR any more, but it restarts in userland because that's the most portable thing to do.
Quoted 2 lines · On Fri, 3 Nov 2000 [email protected] wrote:
After reading about
SA_RESTART, ok. However, couldn't those applications that require it enable this behaviour explicitly?
anyone sane writing modern applications will use sigaction(). signal() is legacy.
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · On Fri, 3 Nov 2000 [email protected] wrote:
Considering that the threading library for Linux uses signals to make it work, would it be possible to change the Linux kernel to operate the way BSD does--instead of returning EINTR, just restart the interrupted primitive?
It's just how the default for signal() is set up by the 'C' runtime library. Instead of using signal, use sigaction(), set the SA_RESTART flag and you have BSD action.
It is also possible to compile existing applications using
-D_BSD_SIGNALS (this is from memory, it might not be exactly correct).
New applications should not use signal(), then should use sigaction() which gives POSIX-defined fine control over the signal handler.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/