[#105450] [Ruby master Feature#18228] Add a `timeout` option to `IO.copy_stream` — "byroot (Jean Boussier)" <noreply@...>
Issue #18228 has been reported by byroot (Jean Boussier).
11 messages
2021/09/27
[ruby-core:105234] [Ruby master Bug#17624] Ractor.receive is not thread-safe
From:
"mame (Yusuke Endoh)" <noreply@...>
Date:
2021-09-14 01:40:39 UTC
List:
ruby-core #105234
Issue #17624 has been updated by mame (Yusuke Endoh).
Assignee set to ko1 (Koichi Sasada)
----------------------------------------
Bug #17624: Ractor.receive is not thread-safe
https://bugs.ruby-lang.org/issues/17624#change-93642
* Author: dazuma (Daniel Azuma)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
It does not seem to be possible to have multiple blocked `Ractor.receive` calls concurrently in the same Ractor (but different threads). One may succeed but the others will hang indefinitely, even if messages are present in the queue.
Example code below. It does the following:
1. Starts a Ractor `r1` that spawns two "listener threads". Each thread calls `Ractor.receive`, which blocks waiting for messages.
2. The main Ractor pauses briefly to ensure that the threads have started, and then sends two messages to the Ractor `r1`, with the expectation that each thread will receive one of them.
3. What actually happens is, the `Ractor.receive` call in *one* of the threads will pick a message and return. However, the `Ractor.receive` call in the other thread remains blocked, even though the second message is in the queue.
4. Ractor `r1`, after a pause to ensure that both messages have been sent, issues another `Ractor.receive` call. This call does not block (because the second message is in the queue), and successfully returns the message. Meanwhile, the second thread's `Ractor.receive` call remains blocked. This demonstrates that the second message has been sent successfully and is receivable, even though the second thread still hasn't returned it. It appears that the second thread's receive call is in a bad state.
```
r1 = Ractor.new do
# Start two listener threads
t1 = Thread.new do
puts "T1 received #{Ractor.receive}"
end
t2 = Thread.new do
puts "T2 received #{Ractor.receive}"
end
# Pause to ensure that both messages have been sent.
# (One of the messages will have been picked up by a
# thread, but the other remains in the queue.)
sleep(3)
# Receive the second message. This will succeed, even
# though the second thread is still blocked.
puts "Later received #{Ractor.receive}"
# Wait for the threads to finish.
# This will never complete because one of the threads will not
# receive the second message, and is still blocking.
[t1, t2].each(&:join)
:ok
end
# Make sure both receive calls are blocking
sleep(1)
# Send two messages.
r1.send(1)
r1.send(2)
# This never returns because the ractor never completes.
puts r1.take
```
This happens both in 3.0.0 release and on 3.1.0 head.
```
% ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```
```
% ruby -v
ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20]
```
Notes:
* This also happens when using `receive_if`.
* I would expect this use case to be common when writing a Ractor that contains multiple thread-safe "workers". (This was in fact the use case I was trying to implement when I encountered this issue.) Thus, if we decide this is working as intended, we should document it, and possibly suggest to users that they write their Ractor to funnel communication through a single dedicated thread.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>