Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Close bug 0004023: usleep feature #68
This got me thinking about the behavior of sleep(f) with respect to signals (those that are handled). sleep() can be interrupted and return early in this case, but since Unix.sleep ignores the return code of sleep(), execution continues on the Caml side, albeit earlier than planned. With Unix.select and the proposed Unix.sleepf, interrupting select() results in a Unix_error exception, which is probably not what we want.
I'm tempted to implement what it takes in Unix so that Unix.sleep/sleepf restart by themselves in case of interrupt, and return only when the requested time elapsed. Any objections to this new behavior? I think it is closer to the user's intent than what we have currently.
On 11/11/2015 07:28 PM, Xavier Leroy wrote:
This would make Unix.sleep(f) consistent with Unix.write, and SIGINT -> Sys.break (on Sys.catch_break true) would keep working right?
How about also providing the user with the ability to turn on SA_RESTART for signal handlers installed by OCaml? This won't help with sleep/select but at least for C libraries on POSIX I found that to work more reliably than trying to fix every library to handle EINTR correctly (e.g. SQLite http://sqlite.1065341.n5.nabble.com/SQLite3-and-EINTR-td73118.html)
Implemented in commit [trunk 50648ed], including the "restart on EINTR" behavior.
@edwintorok : yes, if the signal handler raises an exception (a la Sys.catch_break true), the exception terminates the sleep. Concerning SA_RESTART, it is not POSIX, just a BSD and Linux extension. Moreover, it doesn't apply uniformly to all system calls. For example, under Linux, nanosleep() always return with EINTR on an handled signal. See "man 7 signal" for details.