Fix luv signals (issue #400)

[haesbaert]

This makes sure we can process signals in luv the same way we do in uring. As stated in #400 the main issue is that luv's mainloop will restart on EINTR and we will never unwind back to ocaml land, so even though the process got the signal, the runtime will not see it until something else goes on.

The trick here is to abuse POSIX thread semantics and shove all signals into one specific systhread by blocking them in the other threads.

Additionally, I've fixed a bug in Ocaml 5.0 where the systhreads end up starting with all signals blocked: ocaml/ocaml#11880. This PR works even with/without the bug.

Danger Zone

This is tricky ! If you're thinking we can do better than pipes, think again ! Unix.sigsuspend doesn't work on multithreaded, we don't have a real Unix.pause (it's implemented on top of sigsuspend !).
The semantics for kill(2) to "self" are different than "from outside" when multithreaded, and the runtime doesn't expose pthread_kill(2). That's why on the test we have to fork and signal back to the parent. I know, it's horrible.

[talex5]

Do we really want a thread and not a domain? As I understand it, a thread is attached to a domain and can't run while another thread in that domain is running. So if domain 0 is busy doing CPU stuff then no other domains will be able to get signals I think.

[haesbaert]

Do we really want a thread and not a domain? As I understand it, a thread is attached to a domain and can't run while another thread in that domain is running. So if domain 0 is busy doing CPU stuff then no other domains will be able to get signals I think.

I wouldn't really worry about it being busy, signals are already delayed and not supposed to be realtime.

Having it as a Domain would break the consecutive ids if people want to store things per-domain somehow, as the first Domain spawned by EIO would be id 2 and not 1.

Another issue is that having one an extra idle Domain, even if completely idle, can slow things considerably (see ocaml-multicore/domainslib#77 (comment)) since everyone has to take part in GC, having more Domains are a nono for now.

A third and minor point would be keeping things similar to other backends, the systhread is a hack/deviation of the luv backend, but the things we do in a Domain remain the same in luv/uring/whatever, as in they do heavy bulk.

[talex5]

Thinking about this more, I don't think the busy CPU thing will prevent the signal being handled, because OCaml already has safe points to handle this in the single-domain case.

[talex5]

After fixing the compile error, make test_luv failed:

rm -rf _build
EIO_BACKEND=luv dune runtest
File "tests/dune", line 1, characters 0-54:
1 | (mdx
2 |   (package eio_main)
3 |   (deps (package eio_main)))
Command got signal INT.

Are we sure that waitpid will only return after the signal is delivered? Also, I don't think you can use a ref cell here. It needs to be Atomic.t.

I pushed a commit that fixes it for me. Does that look right to you?

[haesbaert]

After fixing the compile error, make test_luv failed:

rm -rf _build
EIO_BACKEND=luv dune runtest
File "tests/dune", line 1, characters 0-54:
1 | (mdx
2 |   (package eio_main)
3 |   (deps (package eio_main)))
Command got signal INT.

Are we sure that waitpid will only return after the signal is delivered? Also, I don't think you can use a ref cell here. It needs to be Atomic.t.

Good point ! Not at all, the signal can arrive, after or before, I did not consider that.
I must have been (un)lucky, I ran make test_luv in a loop for an hour and never triggered it.

Yeah, since the waitpid doesn't hold, a ref cell only would be racy.

I pushed a commit that fixes it for me. Does that look right to you?

Yep 👍