summaryrefslogtreecommitdiff
path: root/bootstraptest/test_ractor.rb
Commit message (Collapse)AuthorAgeFilesLines
* Skip another flaky Ractor test for YJITTakashi Kokubun2022-12-021-1/+1
|
* Skip a couple of Ractor testsTakashi Kokubun2022-12-021-2/+4
| | | | | Koichi plans to rework Ractor implementation to address these failures. He agreed to skip flaky Ractor tests for now.
* Rename --mjit-min-calls to --mjit-call-threshold (#6731)Takashi Kokubun2022-11-141-1/+1
| | | for consistency with YJIT
* [Bug #19081] Show the caller location in warning for RactorNobuyoshi Nakada2022-10-261-0/+6
| | | | | | | The internal location in ractor.rb is not usefull at all. ``` $ ruby -e 'Ractor.new {}' <internal:ractor>:267: warning: Ractor is experimental, ... ```
* Add test for ractor race condition on ivar setsJemma Issroff2022-10-141-0/+39
|
* @@cv is not accessible from non-main ractorsKoichi Sasada2021-12-241-0/+22
| | | | | | | Class variables (@@cv) is not accessible from non-main ractors. But without this patch cached @@cv can be read. fix [Bug #18128]
* prohibit load by `autoload` on non-main RactorKoichi Sasada2021-12-151-0/+11
| | | | fix [Bug #18120]
* `Ractor.make_shareable` checks proc's seflKoichi Sasada2021-12-091-12/+20
| | | | | | | `Ractor.make_shareable(proc_obj)` raises an `IsolationError` if the self of `proc_obj` is not a shareable object. [Bug #18243]
* rb_id_serial_to_id: return unregistered ID as an internal IDNobuyoshi Nakada2021-11-071-0/+36
| | | | | | | | | | | | | | | | ```ruby def foo(*); ->{ super }; end ``` This code makes anonymous parameters which is not registered as an ID. The problem is that when Ractors try to scan `getlocal` instructions, it puts the Symbol corresponding to the parameter in to a hash. Since it is not registered, we end up with a strange exception. This commit wraps the unregistered ID in an internal ID so that we get the same exception for `...` as `*`. Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org> Co-Authored-By: John Hawthorn <john@hawthorn.email>
* the core problem is the Proc is not shareableSatoshi Moris Tagomori2021-10-271-1/+1
|
* allow to access ivars of classes/modulesKoichi Sasada2021-10-231-1/+48
| | | | | if an ivar of a class/module refer to a shareable object, this ivar can be read from non-main Ractors.
* Fix Ractor.make_shareable changing locals for ProcsAlan Wu2021-10-061-0/+22
| | | | | | | | | | | | | env_copy() uses rb_ary_delete_at() with a loop counting up while iterating through the list of read only locals. rb_ary_delete_at() can shift elements in the array to an index lesser than the loop index, causing locals to be missed and set to Qfalse in the returned environment. Iterate through the locals in reverse instead, this way the shifting never happens for locals that are yet to be visited and we process all the locals in the array. [Bug #18023]
* [Bug #18117] Fix Ractor race condition with GCPeter Zhu2021-08-241-0/+15
| | | | | | | | | | | | | | 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>
* Prefer qualified names under ThreadNobuyoshi Nakada2021-06-291-1/+1
|
* Evacuate transient heap when enabling ractorseileencodes2021-06-231-0/+13
| | | | | | | | | | | 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>
* bootstraptest/test_ractor.rb: Skip an assertion on Travis arm64.Jun Aruga2021-05-251-1/+2
| | | | | | 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>.
* Make Ractor stdio belonging to the Ractor [Bug #17672]Nobuyoshi Nakada2021-03-071-0/+12
| | | | | Defer making ractor stdio until ractor started. Before ractor started, created objects belong to the caller ractor instead of the created ractor.
* Ractor.allocate should not be allowedKoichi Sasada2021-02-181-0/+18
| | | | | Ractor.allocate and Ractor#dup should not be allowed like Thread. [Bug #17642]
* Fixed race in dtoa [Bug #17612]Nobuyoshi Nakada2021-02-101-0/+11
| | | | | | | | | | 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>
* Implement NameError::message#clone for RactorNobuyoshi Nakada2021-02-011-0/+13
|
* fix Ractor.yield(obj, move: true)Koichi Sasada2021-01-221-0/+25
| | | | | | | | | | | | | | | | 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).
* enable constant cache on ractorsKoichi Sasada2021-01-051-0/+12
| | | | | | | | | | | | | | | | 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.
* add Ractor.mainKoichi Sasada2020-12-221-0/+7
| | | | | It returns main Ractor, like Thread.main. [Feature #17418]
* add Ractor#[]/#[]= for ractor local storageKoichi Sasada2020-12-221-0/+14
| | | | | This API is similar to plain old Thread#[]/Fiber#[] interface with symbol key.
* TracePoint.new(&block) should be ractor-localKoichi Sasada2020-12-221-0/+13
| | | | | TracePoint should be ractor-local because the Proc can violate the Ractor-safe.
* fix Ractor.make_shareable() with Class/ModuleKoichi Sasada2020-12-211-1/+8
| | | | | To check shareable-ness, rb_ractor_shareable_p() is needed for Class/Module objects isntead of checking flags.
* add "copy: true" option for Ractor.make_shareableKoichi Sasada2020-12-191-0/+16
| | | | | | | | | | 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.
* strip trailing spaces [ci skip]Nobuyoshi Nakada2020-12-161-2/+2
|
* Ractor#receive_if to receive only matched messagesKoichi Sasada2020-12-161-0/+58
| | | | | | | Instead of Ractor.receive, Ractor.receive_if can provide a pattern by a block and you can choose the receiving message. [Feature #17378]
* trap on non-main ractorKoichi Sasada2020-12-121-0/+18
| | | | | 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.
* fix ivar with shareable objects issueKoichi Sasada2020-12-121-0/+47
| | | | | Instance variables of sharable objects are accessible only from main ractor, so we need to check it correctly.
* ObjectSpace._id2ref should not support unshareableKoichi Sasada2020-12-101-0/+13
| | | | | | 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.
* Add test that `Ractor.make_shareable` calls user defined `#freeze`Marc-Andre Lafortune2020-12-081-1/+8
|
* Ractor.select requires an argument or yield_valueMarc-Andre Lafortune2020-12-071-0/+9
|
* fix Thread's interrupt and Ractor#take issueKoichi Sasada2020-12-071-0/+20
| | | | | | | | | 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.
* should not use rb_str_modify(), tooKoichi Sasada2020-12-011-1/+9
| | | | | | Same as 8247b8edde, should not use rb_str_modify() here. https://bugs.ruby-lang.org/issues/17343#change-88858
* should not use rb_ary_modify()Koichi Sasada2020-12-011-0/+7
| | | | | | | | | | | 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
* Fix `Ractor.make_shareable` for recursive structures with unfreezable componentsMarc-Andre Lafortune2020-11-301-0/+11
| | | | Followup to #3823
* Fixed Ractor.shareable? on cross-recursive objects [Bug #17344]Nobuyoshi Nakada2020-11-301-0/+9
|
* Skip test_ractor.rb:137 for --jit-min-calls=5Takashi Kokubun2020-11-241-1/+1
| | | | | | | | | 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.
* Report a more detailed situation of test_ractor.rb:137Takashi Kokubun2020-11-241-2/+2
| | | | | 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.
* remove Ractor#closeKoichi Sasada2020-11-111-2/+2
| | | | | | | | | | | | 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.
* ignore yield_atexit if outgoing port is closedKoichi Sasada2020-11-111-0/+10
| | | | | If outgoing_port is closed, Ractor.yield never successes. [Bug #17310]
* Threads in a ractor will be killed with the ractorKoichi Sasada2020-11-111-1/+33
| | | | | If a terminating ractor has child threads, then kill all child threads.
* Copy for Ractor.send() without marshal.Koichi Sasada2020-11-021-1/+1
| | | | Now copying objects do not need marshal protocol.
* add a test of define_method with shareable Proc.Koichi Sasada2020-10-301-0/+11
| | | | | | | 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(a_proc)Koichi Sasada2020-10-301-0/+27
| | | | | | | | | | | | | | | | | | | 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]
* Use 'shareable' with an 'e' [ci skip]Marc-Andre Lafortune2020-10-251-8/+8
|
* Tweak a few Ractor tests that were missing comments [ci skip]Marc-Andre Lafortune2020-10-251-0/+4
|
* Remove trailing whitespace [ci skip]Marc-Andre Lafortune2020-10-251-1/+1
|
View Lorry Controller Status