Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime, syscall: SA_RESTART does not affect all system calls #9785

Closed
PieterD opened this issue Feb 5, 2015 · 4 comments
Closed

runtime, syscall: SA_RESTART does not affect all system calls #9785

PieterD opened this issue Feb 5, 2015 · 4 comments

Comments

@PieterD
Copy link
Contributor

PieterD commented Feb 5, 2015

http://man7.org/linux/man-pages/man7/signal.7.html

The following interfaces are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler:

What follows is a list of system calls including "File descriptor multiplexing interfaces" and "System V IPC interfaces" (and inotify before Linux 3.8, which is how I found out in the first place: see #9782).

The standard library should be checked for use of these system calls and, where required, keep EINTR in mind.

@mikioh mikioh changed the title stdlib: SA_RESTART does not affect all system calls runtime, syscall: SA_RESTART does not affect all system calls Feb 5, 2015
@davecheney
Copy link
Contributor

This is why we can't have nice things.
On 6 Feb 2015 10:12, "Pieter Droogendijk" notifications@github.com wrote:

http://man7.org/linux/man-pages/man7/signal.7.html

The following interfaces are never restarted after being interrupted by a
signal handler, regardless of the use of SA_RESTART; they always fail with
the error EINTR when interrupted by a signal handler:

What follows is a list of system calls including "File descriptor
multiplexing interfaces" and "System V IPC interfaces" (and inotify before
Linux 3.8, which is how I found out in the first place: see #9782
#9782).

The standard library should be checked for use of these system calls and,
where required, keep EINTR in mind.


Reply to this email directly or view it on GitHub
#9785.

@bradfitz
Copy link
Contributor

bradfitz commented Feb 7, 2015

/cc @ianlancetaylor for thoughts.

@bradfitz bradfitz added this to the Go1.5Maybe milestone Feb 7, 2015
@ianlancetaylor
Copy link
Contributor

My only thought is that the last time I looked at this they were all handled correctly. I have no objection to somebody else checking.

@rsc
Copy link
Contributor

rsc commented Jul 21, 2015

Unless you know of a specific problem, I don't see any work here.

@rsc rsc closed this as completed Jul 21, 2015
@golang golang locked and limited conversation to collaborators Jul 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants