Hey @danielpclark,
First of all, thank you for creating Rutie, I've been successfully using it in a project and the experience has been very positive.
I have a feature in mind that I'd love to see in Rutie. Since Ruby 3 we now have a Fiber::SchedulerInterface that exposes a way to write Fiber-based concurrency without manual scheduling of the fiber execution. It's based on hinting the optional Fiber scheduler that the current operation is blocking and it can go and do something else and then again when the operation is complete and we can unblock. It's kinda like releasing the GVL allowing other Threads to be scheduled, but for Fibers.
From what I can tell we only need to expose 2 methods to be able to tell Ruby that we're blocked/unblocked.
Putting this out there for anyone to pick before I find some time to put together a PR.
Hey @danielpclark,
First of all, thank you for creating Rutie, I've been successfully using it in a project and the experience has been very positive.
I have a feature in mind that I'd love to see in Rutie. Since Ruby 3 we now have a
Fiber::SchedulerInterfacethat exposes a way to write Fiber-based concurrency without manual scheduling of the fiber execution. It's based on hinting the optional Fiber scheduler that the current operation is blocking and it can go and do something else and then again when the operation is complete and we can unblock. It's kinda like releasing the GVL allowing other Threads to be scheduled, but for Fibers.From what I can tell we only need to expose 2 methods to be able to tell Ruby that we're blocked/unblocked.
Putting this out there for anyone to pick before I find some time to put together a PR.