From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 96EF71F4B4 for ; Thu, 1 Apr 2021 20:49:30 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0760A1210EF; Fri, 2 Apr 2021 05:48:22 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 786641210EE for ; Fri, 2 Apr 2021 05:48:19 +0900 (JST) Received: by filterdrecv-p3mdw1-85cc49d4fc-4pc2m with SMTP id filterdrecv-p3mdw1-85cc49d4fc-4pc2m-19-606631CA-72 2021-04-01 20:49:14.886125041 +0000 UTC m=+785779.788126899 Received: from herokuapp.com (unknown) by ismtpd0140p1iad2.sendgrid.net (SG) with ESMTP id kdUbz2GkTO2FutSTIVQBqA for ; Thu, 01 Apr 2021 20:49:14.805 +0000 (UTC) Date: Thu, 01 Apr 2021 20:49:14 +0000 (UTC) From: headius@headius.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79202 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 12689 X-Redmine-Issue-Author: headius X-Redmine-Sender: headius X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?FFqrkVUH+vvTO0v2jw+akFtsx0ctu2v3V2wlBAc+sNqsP4qciHy3QWd+7i1Uor?= =?us-ascii?Q?HunNqPNKnHYaYeJhax+JsZHTDdidJGguEWvEtJe?= =?us-ascii?Q?=2FLjNJ0lSry1RWsoIAR6sXFcibD2csWJWen0AgJC?= =?us-ascii?Q?ws0fEhyHI8JAugDn0rvNHmV4fEE5oMGH8qLiyVL?= =?us-ascii?Q?6=2FkFr+rBhPMwoz36xTSXgF+hT+kHU+DMCHmJXgj?= =?us-ascii?Q?HgrzVMCJYDoyHzbKs=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103159 Subject: [ruby-core:103159] [Ruby master Bug#12689] Thread isolation of $~ and $_ X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #12689 has been updated by headius (Charles Nutter). Waking this up a bit... The original issue that prompted this bug report has now been FIXED in JRuby 9.2.17.0 by making String#split never read backref from the frame-local storage: https://github.com/jruby/jruby/pull/6644 Further improvements will come in 9.3 with the following PR, which eliminates ALL core method reads of backref (none of them used its contents anyway, and only read it to reuse it): https://github.com/jruby/jruby/pull/6647 With these changes, all concurrency issues surrounding $~ *within core methods* are resolved. Users that opt into using `$~` via the variable or methods like `last_match` will still have to take care that the value is not being updated across threads, but such updates will not interfere with any `$~`-related methods in JRuby 9.3. ---------------------------------------- Bug #12689: Thread isolation of $~ and $_ https://bugs.ruby-lang.org/issues/12689#change-91231 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- We are debating what is correct behavior now, and what should be correct behavior in the future, for the thread-visibility of the special variables `%~` and `$_` We have several examples from https://github.com/jruby/jruby/issues/3031 that seem to exhibit conflicting behavior...or at least the behavior is unexpected in many cases. ``` $ ruby23 -e 'p = proc { p $~; "foo" =~ /foo/ }; Thread.new {p.call}.join; Thread.new{p.call}.join' nil nil $ ruby23 -e 'def foo; proc { p $~; "foo" =~ /foo/ }; end; p = foo; Thread.new {p.call}.join; Thread.new{p.call}.join' nil # $ ruby23 -e 'p = proc { p $~; "foo" =~ /foo/ }; def foo(p); Thread.new {p.call}.join; Thread.new{p.call}.join; end; foo(p)' nil # $ ruby23 -e 'class Foo; P = proc { p $~; "foo" =~ /foo/ }; def foo; Thread.new {P.call}.join; Thread.new{P.call}.join; end; end; Foo.new.foo' nil # $ ruby23 -e 'def foo; p = proc { p $~; "foo" =~ /foo/ }; Thread.new {p.call}.join; Thread.new{p.call}.join; end; foo' nil nil $ ruby23 -e 'def foo; p = proc { p $~; "foo" =~ /foo/ }; bar(p); end; def bar(p); Thread.new {p.call}.join; Thread.new{p.call}.join; end; foo' nil # ``` These cases exhibit some oddities in whether $~ (and presumably $_) are shared across threads. The immediate thought is that they should be both frame and thread-local...but ko1 points out that such a change would break cases like this: ``` def foo /foo/ =~ 'foo' Proc.new{ p $~ } end Thread.new{ foo.call }.join ``` So there's a clear conflict here. Users sometimes expect the $~ value to be shared across threads (at least for read, as in ko1's example) and sometimes do not want it shared at all (as in the case of https://github.com/jruby/jruby/issues/3031 Now we discuss. -- https://bugs.ruby-lang.org/