[#83773] [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769 — usa@...
Issue #14108 has been updated by usa (Usaku NAKAMURA).
9 messages
2017/11/15
[#83774] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
usa@garbagecollect.jp wrote:
[#83775] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— "U.NAKAMURA" <usa@...>
2017/11/15
Hi, Eric
[#83779] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#83781] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— "U.NAKAMURA" <usa@...>
2017/11/15
Hi, Eric,
[#83782] Re: [Ruby trunk Bug#14108] Seg Fault with MinGW on svn 60769
— Eric Wong <normalperson@...>
2017/11/15
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[ruby-core:83932] [Ruby trunk Bug#12689] Thread isolation of $~ and $_
From:
eregontp@...
Date:
2017-11-28 20:32:30 UTC
List:
ruby-core #83932
Issue #12689 has been updated by Eregon (Benoit Daloze).
FWIW, TruffleRuby always stores the MatchData $? in a thread-local storage per frame.
It seems to work fine so far and seems to cause no real-world incompatibilities.
----------------------------------------
Bug #12689: Thread isolation of $~ and $_
https://bugs.ruby-lang.org/issues/12689#change-67982
* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v:
* 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/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>