From: "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...> Date: 2024-03-12T21:25:25+00:00 Subject: [ruby-core:117123] [Ruby master Feature#20276] Introduce Fiber interfaces for Blocking operations on Ractors Issue #20276 has been updated by ioquatix (Samuel Williams). If I had to take a guess, I'd say it's a bug with waiting on a Ractor while handling signals? ---------------------------------------- Feature #20276: Introduce Fiber interfaces for Blocking operations on Ractors https://bugs.ruby-lang.org/issues/20276#change-107198 * Author: forthoney (Seong-Heon Jung) * Status: Feedback ---------------------------------------- ### Motivation I am trying to build a web server with Ractors. The lifecycle for a request in the current implementation is 1. main ractor sends request to worker ractor 2. worker ractor handles response 3. worker ractor sends response to main ractor 4. main ractor writes response 5. repeat The main ractor utilizes the Async gem (specifically async-http) to handle connections concurrently, meaning each request is handled on a separate fiber. The issue I am running into is after I send a request to a worker ractor, I need to do a blocking wait until I receive a response. While I am waiting for the response, I cannot take any more connections. ### Solution If the fiber scheduler had a hook for `Ractor.receive` or `Ractor#take` (both of which are blocking), the main ractor can send the message, handle other connections while the worker processes the request. When the worker produces a message, it will then take the reqeust and write it in the socket. Specifically, I think the `block` and `unblock` hooks should be implemented for Ractors, considering Threads and Mutexes already use them. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/