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

Retry system calls failing with EINTR #7508

Closed
vicuna opened this issue Mar 24, 2017 · 4 comments
Closed

Retry system calls failing with EINTR #7508

vicuna opened this issue Mar 24, 2017 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Mar 24, 2017

Original bug ID: 7508
Reporter: goswin
Status: acknowledged (set by @xavierleroy on 2017-03-24T17:26:21Z)
Resolution: open
Priority: normal
Severity: feature
Category: standard library
Monitored by: @diml @yallop

Bug description

I want to push worward something python did recently:

https://www.python.org/dev/peps/pep-0475/

== Abstract ==

System call wrappers provided in the standard library should be retried automatically when they fail with EINTR , to relieve application code from the burden of doing so.

By system calls, we mean the functions exposed by the standard C library pertaining to I/O or handling of other system resources.

== Rationale ==
=== Interrupted system calls ===

On POSIX systems, signals are common. Code calling system calls must be prepared to handle them. Examples of signals:

The most common signal is SIGINT , the signal sent when CTRL+c is pressed. By default, Python raises a KeyboardInterrupt exception when this signal is received.
When running subprocesses, the SIGCHLD signal is sent when a child process exits.
Resizing the terminal sends the SIGWINCH signal to the applications running in the terminal.
Putting the application in background (ex: press CTRL-z and then type the bg command) sends the SIGCONT signal.

Writing a C signal handler is difficult: only "async-signal-safe" functions can be called (for example, printf() and malloc() are not async-signal safe), and there are issues with reentrancy. Therefore, when a signal is received by a process during the execution of a system call, the system call can fail with the EINTR error to give the program an opportunity to handle the signal without the restriction on signal-safe functions.

In ocaml a signal is caught and recorded in the GC and the next time a GC sequence point is hit the ocaml signal handler is called. Which I believe is eaxctly the same as in Python and we can go the same way to make writing signal safe code more easy. The Unix and Thread modules are directly affected although IO functions in Pervasives should be checked too.

Steps to reproduce

Try using the Graphics module under unix in combination with Unix.sleep. Graphics uses SIGIO to monitor the X connection and thereby aborts the Unix.sleep at random times.

@vicuna
Copy link
Author

vicuna commented Mar 24, 2017

Comment author: @xavierleroy

There are connections with this Github pull request: #1107

@vicuna
Copy link
Author

vicuna commented Mar 27, 2017

Comment author: goswin

Unix.sleep in 4.06.0+dev0-2017-02-15 handles EINTR internally and aborts the sleep early when the signal handler throws an exception (if nanosleep or select is available, the sleep syscall is to imprecise to retry). Exactly as requested in this issue.

Unix.select on the other hand still returns Unix.Unix_error(Unix.EINTR, "select", ""). Didn't check anything else after that.

@github-actions
Copy link

github-actions bot commented May 8, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 8, 2020
@stedolan stedolan self-assigned this May 14, 2020
@stedolan stedolan removed the Stale label May 27, 2020
@gadmm gadmm mentioned this issue Jul 7, 2020
1 task
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants