01:37 <companion_cube> hu, one of the neovim code devs is interested in OCaml it seems

01:49 <discocaml> <cemerick> yeah, eio cancellation is just asking the switch / its fibers "pretty please"

01:50 <discocaml> <cemerick> _if_ you do IO (maybe only eio IO, not sure?) then ofc the requested cancellation will tangibly occur, but a long-running IO-free computation will not be halted

01:53 <discocaml> <cemerick> there's still sadiq's suggestion re: using a signal handler, the blast radius of which can apparently be narrowed to a particular domain? The comment @ https://github.com/ocaml/ocaml/issues/11411#issuecomment-1179153453 alludes to this, which I need to research

01:54 <companion_cube> tbh you probably need to run long CPU computations on a background domain via domainslib

01:54 <companion_cube> not on the Eio thread

02:02 <discocaml> <darrenldl> you can run it in a different domain through eio's domain manager

02:03 <discocaml> <darrenldl> but yeah, last i looked at eio's scheduling, it is very cooperative

02:05 <discocaml> <cemerick> eh, it seems I really do need to actually run an experiment; Xavier points out that pending exceptions are checked for upon non-C allocations, so either eio cancellation or a thread-masked signal may well be tripped over in a CPU-bound thread/fiber, as long as its task allocs somewhere

02:05 <discocaml> <cemerick> (which is a fine presumption for my use case anyway)

02:06 <discocaml> <cemerick> I assume the experiment will fail tho; if this were to work, then this wouldn't be a problem for coq anymore

02:54 <discocaml> <darrenldl> would be keen to hear a followup - if cancellation indeed preempts that would be very convenient

04:35 <pgiarrusso> 3:50 AM <discocaml> <cemerick> a long-running IO-free computation will not be halted

04:36 <pgiarrusso> Isn’t that why the MR adds polls to backwards jumps in loops?

04:39 <pgiarrusso> Also, at starts of functions

04:40 <pgiarrusso> They don't add polls to function returns, so worst-case latency is linear with max stack size, but still finite

04:41 <companion_cube> I thought the polls where for the GC

04:41 <companion_cube> so that major collections can freez all threads

04:41 <companion_cube> +e

07:55 <sadiq> minor collections stop the world. major collections do right at the final bit.

07:55 <sadiq> the polling changes will also ensure that OCaml signal handlers will run, even in tight loops

13:20 <discocaml> <cemerick> so there's a number of challenges with using signals. First, it seems one cannot use signals between threads (per https://v2.ocaml.org/api/Thread.html#1_Managementofsignals, "signals generated by a thread are delivered to that thread"). Even if that were resolvable (maybe have a separate reaper process that sends a heartbeat of quit signals? 🤢), there's no way to control on _which_ thread the signal handler is run, an obvious problem if on