| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rb_objspace_reachable_objects_from requires that the GC not be active.
Since the Ractor barrier is not executed for incremental sweeping,
Ractor may call rb_objspace_reachable_objects_from after sweeping
has started to share objects. This causes a crash that looks like
the following:
```
<internal:ractor>:627: [BUG] rb_objspace_reachable_objects_from() is not supported while during_gc == true
```
Co-authored-by: Vinicius Stock <vinicius.stock@shopify.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the GC has been disabled we need to re-enable it so we can evacuate
the transient heap.
Fixes https://bugs.ruby-lang.org/issues/17985
[Bug #17985] [ruby-core:104260]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
|
|
|
|
|
|
| |
Skip the assertion to test the `Ractor.select` from multiple ractors that rarely
fails on Travis arm64.
See <https://bugs.ruby-lang.org/issues/17878>.
|
|
|
|
|
| |
Defer making ractor stdio until ractor started.
Before ractor started, created objects belong to the caller ractor
instead of the created ractor.
|
|
|
|
|
| |
Ractor.allocate and Ractor#dup should not be allowed like Thread.
[Bug #17642]
|
|
|
|
|
|
|
|
|
|
| |
Fixed the race condition when replacing `freelist` entry with its
chained next element. At acquiring an entry, hold the entry once
with the special value, then release by replacing it with the next
element again after acquired. If another thread is holding the
same entry at that time, spinning until the entry gets released.
Co-Authored-By: Koichi Sasada <ko1@atdot.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ractor.yield(obj, move: true) and
Ractor.select(..., yield_value: obj, move: true) tried to yield a
value with move semantices, but if the trial is faild, the obj
should not become a moved object.
To keep this rule, `wait_moving` wait status is introduced.
New yield/take process:
(1) If a ractor tried to yield (move:true), make taking racotr's
wait status `wait_moving` and make a moved object by
`ractor_move(obj)` and wakeup taking ractor.
(2) If a ractor tried to take a message from a ractor waiting fo
yielding (move:true), wakeup the ractor and wait for (1).
|
|
|
|
|
|
|
|
| |
because the name "MJIT" is an internal code name, it's inconsistent with
--jit while they are related to each other, and I want to discourage future
JIT implementation-specific (e.g. MJIT-specific) APIs by this rename.
[Feature #17490]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant cache `IC` is accessed by non-atomic manner and there are
thread-safety issues, so Ruby 3.0 disables to use const cache on
non-main ractors.
This patch enables it by introducing `imemo_constcache` and allocates
it by every re-fill of const cache like `imemo_callcache`.
[Bug #17510]
Now `IC` only has one entry `IC::entry` and it points to
`iseq_inline_constant_cache_entry`, managed by T_IMEMO object.
`IC` is atomic data structure so `rb_mjit_before_vm_ic_update()` and
`rb_mjit_after_vm_ic_update()` is not needed.
|
|
|
|
|
| |
It returns main Ractor, like Thread.main.
[Feature #17418]
|
|
|
|
|
| |
This API is similar to plain old Thread#[]/Fiber#[] interface
with symbol key.
|
|
|
|
|
| |
TracePoint should be ractor-local because the Proc can violate the
Ractor-safe.
|
|
|
|
|
| |
To check shareable-ness, rb_ractor_shareable_p() is needed
for Class/Module objects isntead of checking flags.
|
|
|
|
|
|
|
|
|
|
| |
Ractor.make_shareable(obj) tries to make obj a shareable object
by changing the attribute of obj and traversable objects from obj
(mainly freeze them).
"copy: true" option is more conservative approach by make deep
copied object and make it sharable. It doesn't affect any existing
objects.
|
| |
|
|
|
|
|
|
|
| |
Instead of Ractor.receive, Ractor.receive_if can provide a pattern
by a block and you can choose the receiving message.
[Feature #17378]
|
|
|
|
|
|
| |
It's not working
http://ci.rvm.jp/results/trunk-mjit@phosphorus-docker/3288206. I'm
debugging why.
|
| |
|
|
|
|
| |
Because Ruby often fails to dump a C backtrace.
|
|
|
|
|
| |
trap can accept blopck/Proc and it can violate Rator isolation,
so the Proc should be isolatable when trap is used on non-main ractor.
|
|
|
|
|
| |
Instance variables of sharable objects are accessible only from
main ractor, so we need to check it correctly.
|
| |
|
|
|
|
|
|
| |
ObjectSpace._id2ref(id) can return any objects even if they are
unshareable, so this patch raises RangeError if it runs on multi-ractor
mode and the found object is unshareable.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Thread's interrupt set Ractor's wakeup_status as interrupted, but
the status remains next Ractor communication API. This patch makes
to ignore the previous interrupt state.
[Bug #17366]
Also this patch solves the Thread#kill and Ractor#take issues.
|
|
|
|
| |
* Otherwise those tests, etc cannot run on alternative Ruby implementations.
|
|
|
|
|
|
| |
Same as 8247b8edde, should not use rb_str_modify() here.
https://bugs.ruby-lang.org/issues/17343#change-88858
|
|
|
|
|
|
|
|
|
|
|
| |
ractor_copy() used rb_ary_modify() to make sure this array is not
sharing anything, but it also checks frozen flag. So frozen arrays
raises an error. To solve this issue, this patch introduces new
function rb_ary_cancel_sharing() which makes sure the array does not
share another array and it doesn't check frozen flag.
[Bug #17343]
A test is quoted from https://github.com/ruby/ruby/pull/3817
|
|
|
|
| |
Followup to #3823
|
| |
|
|
|
|
|
|
|
|
|
| |
It's failing like
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3270373 but I
have no bandwidth to fix it for now.
We're still checking --jit-wait (without --jit-min-calls=5) on GitHub
Actions.
|
|
|
|
|
| |
This test has been very unstable. I'd like to instantly know whether
it's always failing or random when I look at a CI failure output.
|
|
|
|
|
|
|
|
|
|
|
|
| |
close_incoming by antoher ractor means there is no other messages
will be sent to the ractor, so Ractor.receive will block forever,
and it should raise and stop.
close_outgoing by antoher ractor means, ... I don't have good idea
to use it. It can be a private method.
Ractor#close calls both, but it does not make sense to call
different purpose methods, so I remove it.
|
|
|
|
|
| |
If outgoing_port is closed, Ractor.yield never successes.
[Bug #17310]
|
|
|
|
|
| |
If a terminating ractor has child threads, then kill all child
threads.
|
|
|
|
| |
Now copying objects do not need marshal protocol.
|
|
|
|
|
|
|
| |
a method defined by define_method with normal Proc can not cross
ractors because the normal Proc is not shareable. However,
shareable Proc can be crossed between ractors, so the method with
shareable Proc should be called correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ractor.make_shareable() supports Proc object if
(1) a Proc only read outer local variables (no assignments)
(2) read outer local variables are shareable.
Read local variables are stored in a snapshot, so after making
shareable Proc, any assignments are not affeect like that:
```ruby
a = 1
pr = Ractor.make_shareable(Proc.new{p a})
pr.call #=> 1
a = 2
pr.call #=> 1 # `a = 2` doesn't affect
```
[Feature #17284]
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Accessing a shareable object is prohibitted because it can cause
race condition, but if the shareable object is frozen, there is no
problem to access ivars.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new method Ractor.make_shareable(obj) which tries to make
obj shareable object. Protocol is here.
(1) If obj is shareable, it is shareable.
(2) If obj is not a shareable object and if obj can be shareable
object if it is frozen, then freeze obj. If obj has reachable
objects (rs), do rs.each{|o| Ractor.make_shareable(o)}
recursively (recursion is not Ruby-level, but C-level).
(3) Otherwise, raise Ractor::Error. Now T_DATA is not a shareable
object even if the object is frozen.
If the method finished without error, given obj is marked as
a sharable object.
To allow makng a shareable frozen T_DATA object, then set
`RUBY_TYPED_FROZEN_SHAREABLE` as type->flags. On default,
this flag is not set. It means user defined T_DATA objects are
not allowed to become shareable objects when it is frozen.
You can make any object shareable by setting FL_SHAREABLE flag,
so if you know that the T_DATA object is shareable (== thread-safe),
set this flag, at creation time for example. `Ractor` object is one
example, which is not a frozen, but a shareable object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Solaris, it seems to access ENV in ``, so skip it now.
```
stderr output is not empty
Exception `NameError' at bootstraptest.tmp.rb:7 - can not access non-sharable objects in constant Object::ENV by non-main Ractor.
#<Thread:0x0044cdf0 run> terminated with exception (report_on_exception is true):
bootstraptest.tmp.rb:7:in ``': can not access non-sharable objects in constant Object::ENV by non-main Ractor. (NameError)
Exception `Ractor::RemoteError' at <internal:ractor>:130 - thrown by remote Ractor.
<internal:ractor>:130:in `take': thrown by remote Ractor. (Ractor::RemoteError)
from bootstraptest.tmp.rb:55:in `<main>'
bootstraptest.tmp.rb:7:in ``': can not access non-sharable objects in constant Object::ENV by non-main Ractor. (NameError)
from bootstraptest.tmp.rb:7:in `ractor_local_globals'
from bootstraptest.tmp.rb:54:in `block in <main>'
```
|