@mame If we decide to use `Fiber#kill` for terminating the fiber (which seems reasonable), it seems bad that it may not return to the point that `rb_fiber_kill` was invoked. WDYT? It would be the same issue as discussed in https://bugs....ioquatix (Samuel Williams)
Okay, I spoke too soon, I think this clearly demonstrates the confusion: ```ruby def event_loop loop_fiber = Fiber.new do task = Fiber.new do puts "task" end # scheduler executes the task task.transfer puts "...ioquatix (Samuel Williams)
Actually, this behaviour isn't as bad as I thought it was: ```ruby f1 = Fiber.new do f2 = Fiber.new do puts "f2" end.transfer puts "f1" end.resume f2 f1 ``` I thought f2 would transfer back out to the main fiber, but it goe...ioquatix (Samuel Williams)
I think the crux of the issue here is that there is no way to do a final transfer (or raise that transfers) that goes back to a specific fiber, but it probably should be possible. ```ruby fiber = Fiber.new do # Do stuff
Add a new flag, `RB_NOGVL_PENDING_INTERRUPT_FAIL`, to `rb_nogvl()`. When set, `rb_nogvl()` does not enter the blocking region (does not call the supplied function) if the current thread has *pending interrupts* — including interrupts tha...ioquatix (Samuel Williams)
Following up on my earlier comment, now that we have implemented `process_wait` across several backends (including the `io_uring` `waitid` path) and worked through the edge cases in practice. The implementation experience gives concrete ...ioquatix (Samuel Williams)
Ruby's default SIGINT handling currently bypasses `Thread.handle_interrupt` masking. When a process receives SIGINT with the default Ruby handler installed, CRuby calls `rb_interrupt()` directly. That can raise `Interrupt` immediately in...ioquatix (Samuel Williams)
ioquatix (Samuel Williams)06:19 AM Ruby Feature #21957: Introduce `Enumerable#close` to free internal resources.