|Anonymous | Login | Signup for a new account||2018-06-19 14:54 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007802||OCaml||standard library||public||2018-06-08 08:36||2018-06-13 02:26|
|Target Version||Fixed in Version|
|Summary||0007802: Shouldn't unix/sleep.c use clock_nanosleep (if available) instead of nanosleep?|
|Description||If deemed useful, I can send a patch.|
|Tags||No tags attached.|
|What would be the benefit of switching to clock_nanosleep?|
Better precision in some specific cases.
Cf. man nanosleep:
If a program that catches signals and uses nanosleep() receives signals
at a very high rate, then scheduling delays and rounding errors in the
kernel's calculation of the sleep interval and the returned remain
value mean that the remain value may steadily increase on successive
restarts of the nanosleep() call. To avoid such problems, use
clock_nanosleep(2) with the TIMER_ABSTIME flag to sleep to an absolute
Thanks. Have you come across an actual situation where the current implementation is problematic or is this request about a potential problem?
Personally I am not familiar with the signal handling code, so I can't say whether this change is worth it or not, but feel free to open a PR if you would like to get wider feedback on this proposal.
I am worried about the potential problem.
As a C programmer, by reading the manpage, I would have used clock_nanosleep
instead of nanosleep (maybe it became available later).
I was reading the C implementation of unix_sleep in otherlibs/unix/sleep.c, which is called by Unix.sleepf.
|2018-06-08 08:36||berenger||New Issue|
|2018-06-08 10:23||nojebar||Note Added: 0019167|
|2018-06-11 02:44||berenger||Note Added: 0019177|
|2018-06-12 15:22||nojebar||Note Added: 0019185|
|2018-06-13 02:26||berenger||Note Added: 0019186|
|Copyright © 2000 - 2011 MantisBT Group|