[ruby-core:121073] [Ruby master Feature#21121] Ractor channels
From:
"shan (Shannon Skipper) via ruby-core" <ruby-core@...>
Date:
2025-02-16 00:53:07 UTC
List:
ruby-core #121073
Issue #21121 has been updated by shan (Shannon Skipper).
This seems really handy. I wonder if it would be worth considering having an optional self-closing block variant?
``` ruby
Ractor::Channel.new do |channel|
# Automatically ensure `channel.close_incoming` and `channel.close_outgoing` on block close.
end
```
An example with a block (not implementing the `buffer` argument) might look something like:
``` ruby
class Ractor
module Channel
def self.new(&block)
channel = Ractor.new do
loop do
Ractor.yield Ractor.receive
end
end
if block_given?
message = block.call(channel)
channel.close_incoming
channel.close_outgoing
return message
end
channel
end
end
end
class Map
def initialize
@reactor = Ractor.new do
cache = {}
loop do
channel, payload = Ractor.receive
channel << cache.public_send(*payload)
end
end
freeze
end
def []=(key, value)
pipe __method__, key, value
end
%i[[] delete key? value?].each do |meth|
define_method(meth) { |key| pipe meth, key }
end
%i[clear empty? keys length size to_a to_h values].each do |meth|
define_method(meth) { pipe meth }
end
private
def pipe(*payload)
Ractor::Channel.new do |channel|
@reactor << [channel, payload]
channel.take
end
end
end
```
----------------------------------------
Feature #21121: Ractor channels
https://bugs.ruby-lang.org/issues/21121#change-111990
* Author: luke-gru (Luke Gruber)
* Status: Open
----------------------------------------
# Motivation:
It would be nice be able to `Ractor.yield` in a non-blocking way. Right now a `Ractor.yield` blocks until another ractor calls `r.take` on the yielding ractor.
This is bad in the following scenario:
```ruby
main = Ractor.current
rs = 10.times.map do
Ractor.new(main) do |m|
ret = []
loop do
# do a bunch of work that takes a while, then:
begin
obj = m.take
rescue Ractor::ClosedError
end
if obj
ret << obj
else
break
end
end
ret
end
end
50.times do |i|
Ractor.yield(i) # this will block until some ractor calls take on us, but it could be a while if there is processing before the `take` call.
end
main.close_outgoing
# Ideally, we could do some work in main ractor that takes some time while the other ractors do their processing. But we're blocking right now
# during all the calls to `Ractor.yield`.
# Finally, get the results
while rs.any?
r, obj = Ractor.select(*rs)
$stderr.puts "Ractor #{r} got #{obj}"
rs.delete(r)
end
```
I'd like other ractors to be able to do work in a "fire and forget" kind of way. It isn't possible right now due to the limitations of `Ractor.yield` and `Ractor#take`.
What we need is some kind of `yield` buffer so the yielder doesn't block. I propose that Ractor channels would allow this type of programming to work.
## Example using channels:
```ruby
chan = Ractor::Channel.new # We could specify buffer size like Go or it could be dynamically growable
rs = 10.times.map do
Ractor.new(chan) do |c|
ret = []
loop do
obj, _closed = c.receive # returns `[nil, true]` if `c` is closed and its buffer is empty. It blocks if the buffer is empty and `c` is not closed.
if obj
ret << obj
else
break
end
end
ret
end
end
50.times do |i|
chan.send(i) # non-blocking, fills a buffer and only wakes a receiver if there is one
end
chan.close
# Do some processing while ractors do their work.
# Then, collect the results
while rs.any?
r, obj = Ractor.select(*rs)
puts "Ractor #{r} got #{obj}"
rs.delete(r)
end
```
With an API similar to this, we could have "fire and forget" processing with ractors.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/