| Age | Commit message (Collapse) | Author |
|---|
| * 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: Merged: https://.com/ruby/ruby/pull/13445 |
| Notes: Merged: https://.com/ruby/ruby/pull/13439 |
| Notes: Merged: https://.com/ruby/ruby/pull/11142 |
| `USE_RUBY_DEBUG_LOG` was only defined when `RUBY_DEVEL` is defined. This removes this dependency (`USE_RUBY_DEBUG_LOG` is defined independently from `RUBY_DEVEL`). Do not commit a which enables `USE_RUBY_DEBUG_LOG`. Notes: Merged: https://.com/ruby/ruby/pull/5366 |
| Notes: Merged: https://.com/ruby/ruby/pull/5345 |
| |
| Notes: Merged: https://.com/ruby/ruby/pull/4003 |
| * vm_sync_lock * vm_sync_lock_enter * vm_sync_lock_enter_nb * vm_sync_lock_enter_cr * vm_sync_barrier Notes: Merged: https://.com/ruby/ruby/pull/3910 |
| Write barrier requires VM lock because it accesses VM global bitmap but RB_VM_LOCK_ENTER() can invoke GC because another ractor can wait to invoke GC and RB_VM_LOCK_ENTER() is barrier point. This means that before protecting by a write barrier, GC can invoke. To prevent such situation, RB_VM_LOCK_ENTER_NO_BARRIER() is introduced. This lock primitive does not become GC barrier points. |
| On windows, MJIT doesn't work without this because of the declaration of ruby_single_main_ractor. This fix this issue and move the definition of it from ractor.c to vm.c to locate near place of ruby_current_vm_ptr. Notes: Merged: https://.com/ruby/ruby/pull/3842 |
| This is variant of RB_VM_LOCK_ENTER_LEV, but accept current racotr's pointer. Notes: Merged: https://.com/ruby/ruby/pull/3842 |
| ruby_multi_ractor was a flag that indicates the interpreter doesn't make any additional ractors (single ractor mode). Instead of boolean flag, ruby_single_main_ractor pointer is introduced which keeps main ractor's pointer if single ractor mode. If additional ractors are created, ruby_single_main_ractor becomes NULL. Notes: Merged: https://.com/ruby/ruby/pull/3842 |
| |
| vm_sync.h does not need to include vm_core.h and ractor_pub.h. Notes: Merged: https://.com/ruby/ruby/pull/3534 |
| rb_ractor_main_p() need to access to the ractor pointer in TLS. However it is slow operation so that we need to skip this check if it is not multi-ractor mode (!ruby_multi_ractor). This performance regression is pointed at https://bugs.ruby-lang.org/issues/17100#note-27 Notes: Merged: https://.com/ruby/ruby/pull/3513 |
| This commit introduces Ractor mechanism to run Ruby program in parallel. See doc/ractor.md for more details about Ractor. See ticket [Feature #17100] to see the implementation details and discussions. [Feature #17100] This commit does not complete the implementation. You can find many bugs on using Ractor. Also the specification will be changed so that this feature is experimental. You will see a warning when you make the first Ractor with `Ractor.new`. I hope this feature can help programmers from thread-safety issues. Notes: Merged: https://.com/ruby/ruby/pull/3365 |
