Comment author: lindig

• Preemption #1533: (a) The implementation of Thread.yield for system thread
  now uses nanosleep(1) for enabling better preemption.
  (b) Thread.delay is now an alias for Unix.sleepf.
  (Jacques-Henri Jourdan, review by Xavier Leroy and David Allsopp)

• Protect Unix.sleep against interruptions by handled signals.
  Before, a handled signal could cause Unix.sleep to return early.
  Now, the sleep is restarted until the given time is elapsed.
  (Xavier Leroy)

Comment author: @edwintorok

It might be useful for the stdlib implementation to reacquire the ocaml runtime lock, run the equivalent of caml_process_signals, and release the runtime lock again (perhaps by tracking how long that took via gettimeofday).
This would allow processing SIGTERM in a timely manner, while still allowing for Thread.delay/sleep to return only after the correct time has elapsed in the common case. (the signal handler could still call exit of course)

Comment author: lindig

diff --git a/otherlibs/systhreads/thread.ml b/otherlibs/systhreads/thread.ml
index ec05f39..bf47d75 100644
--- a/otherlibs/systhreads/thread.ml
+++ b/otherlibs/systhreads/thread.ml
@@ -71,7 +71,7 @@ let () =

(* Wait functions *)

-let delay time = ignore(Unix.select [] [] [] time)
+let delay = Unix.sleepf

let wait_read fd = ()
let wait_write fd = ()

Comment author: lindig

In the case of EINTR the runtime system could check for signals and deliver them.

CAMLprim value unix_sleep(value duration)
{
double d = Double_val(duration);
if (d < 0.0) return Val_unit;
{
struct timespec t;
int ret;
caml_enter_blocking_section();
t.tv_sec = (time_t) d;
t.tv_nsec = (d - t.tv_sec) * 1e9;
do {
ret = nanosleep(&t, &t);
} while (ret == -1 && errno == EINTR);
caml_leave_blocking_section();
if (ret == -1) uerror("sleep", Nothing);
}

Comment author: lindig

Can we get an opinion on this? If the changed in behaviour in OCaml 4.07 is as intended, how should one terminate sleeping threads? it could mean that threads never should sleep long to guarantee that signals can be delivered.

Comment author: @jhjourdan

Can we get an opinion on this? If the changed in behaviour in OCaml 4.07 is as intended, how should one terminate sleeping threads? it could mean that threads never should sleep long to guarantee that signals can be delivered.

Sorry for the delay. I will have a look at some point during the week.

In the case of EINTR the runtime system could check for signals and deliver them.

Indeed, this seems possible. However, the signal handling system in the OCaml runtime is subtle, and we have to make sure this does not have unexpected implications.

Comment author: @xavierleroy

Sorry I didn't see this report earlier. Yes, the 4.07 behavior is not quite right and an unintended consequence.

We could enter/leave around each call to nanosleep:

do {
caml_enter_blocking_section();
ret = nanosleep(&t, &t);
caml_leave_blocking_section();
} while (ret == -1 && errno == EINTR);

I think this would call signal handlers in a timely manner. However, the extra leave / enter calls can take arbitrarily long time, so we can end up sleeping too long.

Comment author: @jhjourdan

However, the extra leave / enter calls can take arbitrarily long time, so we can end up sleeping too long.

Isn't that already the behavior the the libC? I mean, if you write a pure C program which contains time-consuming signal handlers, then the sleep-like functions are not a suitable way of pausing an accurate amount of time.

Comment author: @xavierleroy

Proposed fix at #2306

Comment author: @xavierleroy

Fixed in commit 187ceb6.