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/
next parent 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).