diff options
author | Koichi Sasada <[email protected]> | 2025-05-27 03:58:04 +0900 |
---|---|---|
committer | Koichi Sasada <[email protected]> | 2025-05-31 04:01:33 +0900 |
commit | ef2bb61018cd9ccb5b61a3d91911e04a773da4a7 (patch) | |
tree | fcf3685efc9d3efaa1a66236ad17d2a72b7c5144 /thread.c | |
parent | d2a1ad00cbba41e22c11abf2948c23cd8d68f565 (diff) |
`Ractor::Port`
* Added `Ractor::Port`
* `Ractor::Port#receive` (support multi-threads)
* `Rcator::Port#close`
* `Ractor::Port#closed?`
* Added some methods
* `Ractor#join`
* `Ractor#value`
* `Ractor#monitor`
* `Ractor#unmonitor`
* Removed some methods
* `Ractor#take`
* `Ractor.yield`
* Change the spec
* `Racotr.select`
You can wait for multiple sequences of messages with `Ractor::Port`.
```ruby
ports = 3.times.map{ Ractor::Port.new }
ports.map.with_index do |port, ri|
Ractor.new port,ri do |port, ri|
3.times{|i| port << "r#{ri}-#{i}"}
end
end
p ports.each{|port| pp 3.times.map{port.receive}}
```
In this example, we use 3 ports, and 3 Ractors send messages to them respectively.
We can receive a series of messages from each port.
You can use `Ractor#value` to get the last value of a Ractor's block:
```ruby
result = Ractor.new do
heavy_task()
end.value
```
You can wait for the termination of a Ractor with `Ractor#join` like this:
```ruby
Ractor.new do
some_task()
end.join
```
`#value` and `#join` are similar to `Thread#value` and `Thread#join`.
To implement `#join`, `Ractor#monitor` (and `Ractor#unmonitor`) is introduced.
This commit changes `Ractor.select()` method.
It now only accepts ports or Ractors, and returns when a port receives a message or a Ractor terminates.
We removes `Ractor.yield` and `Ractor#take` because:
* `Ractor::Port` supports most of similar use cases in a simpler manner.
* Removing them significantly simplifies the code.
We also change the internal thread scheduler code (thread_pthread.c):
* During barrier synchronization, we keep the `ractor_sched` lock to avoid deadlocks.
This lock is released by `rb_ractor_sched_barrier_end()`
which is called at the end of operations that require the barrier.
* fix potential deadlock issues by checking interrupts just before setting UBF.
https://bugs.ruby-lang.org/issues/21262
Notes
Notes:
Merged: https://github.com/ruby/ruby/pull/13445
Diffstat (limited to 'thread.c')
-rw-r--r-- | thread.c | 7 |
1 files changed, 4 insertions, 3 deletions
@@ -526,9 +526,6 @@ thread_cleanup_func(void *th_ptr, int atfork) } rb_native_mutex_destroy(&th->interrupt_lock); -#ifndef RUBY_THREAD_PTHREAD_H - rb_native_cond_destroy(&th->ractor_waiting.cond); -#endif } static VALUE rb_threadptr_raise(rb_thread_t *, int, VALUE *); @@ -6174,6 +6171,8 @@ threadptr_interrupt_exec_exec(rb_thread_t *th) } rb_native_mutex_unlock(&th->interrupt_lock); + RUBY_DEBUG_LOG("task:%p", task); + if (task) { (*task->func)(task->data); ruby_xfree(task); @@ -6228,6 +6227,8 @@ rb_ractor_interrupt_exec(struct rb_ractor_struct *target_r, { struct interrupt_ractor_new_thread_data *d = ALLOC(struct interrupt_ractor_new_thread_data); + RUBY_DEBUG_LOG("flags:%d", (int)flags); + d->func = func; d->data = data; rb_thread_t *main_th = target_r->threads.main; |