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

Close bug 0004023: usleep feature #68

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
8 participants
@johnlepikhin
Copy link

commented May 23, 2014

No description provided.

@Kakadu

This comment has been minimized.

Copy link

commented May 23, 2014

You probably need another patch for win32unix...

@edwintorok

This comment has been minimized.

Copy link
Contributor

commented May 27, 2014

There is a C function called usleep that takes as argument microseconds. This function seems to take seconds, won't that cause confusion?

@Chris00

This comment has been minimized.

Copy link
Member

commented May 29, 2014

Note that there is also the problem with signals when used in conjuction with graphics. Maybe a separate function is required.

@murmour

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2014

There is a C function called usleep that takes as argument microseconds. This function seems to take seconds, won't that cause confusion?

Agreed. usleep is a confusing name. Perhaps it would be more appropriate to name it fsleep?

@xavierleroy

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2015

This pull request has been sleeping (pun!) for too long. If we can collectively agree on a name for this alternate "sleep" function, it will get in.

@xavierleroy xavierleroy added the stdlib label Oct 25, 2015

@murmour

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2015

Trivia:

  • There is no function in the stardard library, the name of which has prefix f that stands for float.
  • There is exactly one function name with suffix f that means float — it's modf.

Considering the above, I change my suggestion from fsleep to sleepf.

@SGrondin

This comment has been minimized.

Copy link

commented Oct 25, 2015

I agree with cakeplus.

@damiendoligez

This comment has been minimized.

Copy link
Member

commented Oct 28, 2015

OK for merging as soon as the function is renamed to sleepf and the Changes file is updated.

@johnlepikhin can you make these changes?

@johnlepikhin

This comment has been minimized.

Copy link
Author

commented Oct 28, 2015

OK, I'll do it in the next two days.

@xavierleroy

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2015

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.

@edwintorok

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2015

On 11/11/2015 07:28 PM, Xavier Leroy wrote:

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.

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)

@xavierleroy

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

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.

@Chris00

This comment has been minimized.

Copy link
Member

commented Nov 15, 2015

👍

stedolan added a commit to stedolan/ocaml that referenced this pull request Nov 28, 2016

Merge pull request ocaml#68 from ocamllabs/mark-stack-overflow
Handle mark stack overflow by postponing marking of some pools.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.