ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: headius@headius.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:103159] [Ruby master Bug#12689] Thread isolation of $~ and $_
Date: Thu, 01 Apr 2021 20:49:14 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-91231.20210401204914.286@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-12689.20160819063718.286@ruby-lang.org

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
#<MatchData "foo">

$ ruby23 -e 'p = proc { p $~; "foo" =~ /foo/ }; def foo(p); Thread.new {p.call}.join; Thread.new{p.call}.join; end; foo(p)'
nil
#<MatchData "foo">

$ 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
#<MatchData "foo">

$ 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
#<MatchData "foo">
```

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/

       reply	other threads:[~2021-04-01 20:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-12689.20160819063718.286@ruby-lang.org>
2021-04-01 20:49 ` headius [this message]
2021-04-01 20:51 ` [ruby-core:103160] [Ruby master Bug#12689] Thread isolation of $~ and $_ headius

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-91231.20210401204914.286@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).