ioquatix (Samuel Williams) wrote in #note-7: > If I had to take a guess, I'd say it's a bug with waiting on a Ractor while handling signals? Under closer inspection, the `Thread#join` workaround should work in theory but actually dea...forthoney (Seong-Heon Jung)
When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper ...forthoney (Seong-Heon Jung)
On a side note, I may have unintentionally discovered an IRB bug in the process. If you run the above in IRB and use Ctrl-C to exit, IRB hangs and becomes unresponsive.forthoney (Seong-Heon Jung)
ioquatix (Samuel Williams) wrote in #note-4: > I support this proposal. > ... Tested on locally and it seems to work, at least with Async. Here's my code. ```ruby Async do |task| 1.upto(3) do r = Ractor.new do Ractor.r...forthoney (Seong-Heon Jung)
I think the name is potentially confusing. Consider the following: ```ruby if client.readable? client.read # this may block end ``` I personally would be a bit surprised if `client.read` blocked despite `client.readable?` returni...forthoney (Seong-Heon Jung)
ko1 (Koichi Sasada) wrote in #note-2: > I understand the motivation but now the ractor-thread combination is not well-defined yet and combination with Fiber (scheduler) is also earlier (because of Ractor's specification and implementati...forthoney (Seong-Heon Jung)
### 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 res...forthoney (Seong-Heon Jung)
The docs should explicitly state the semantics/properties of Ractor message, especially when it comes to FIFO. For example, assume I have two Ractors, Ractor A and Ractor B. Ractor A sends two messages `"hello"` and `"world"` in this or...forthoney (Seong-Heon Jung)
luke-gru (Luke Gruber) wrote in #note-3: > I think this is due to not currently being able to move any T_DATA objects between ractors. StringIO is defined in a C extension and is a T_DATA object internally. See https://github.com/ruby/r...forthoney (Seong-Heon Jung)
Thank you for the quick response! If my understanding is correct, then there are 4 categories of Ruby objects: 1. Shareable objects (Ractors, immutable objects, etc) 2. Unshareable but sendable with copy and move 3. Unshareable but s...forthoney (Seong-Heon Jung)
forthoney (Seong-Heon Jung)07:09 PM Ruby Feature #20276: Introduce Fiber interfaces for Blocking operations on Ractors