New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Capture lookup inside regex is not threadsafe #6436
Comments
From @smlsWhen the same regex is used concurrently from multiple `start` threads, ➜ await do for ^10 -> $i { start { "A".match: /(“A”) { say "BOOM: That example shouldn't print anything, because `$0` should always be a But in practice, it demonstrates the incorrect behavior shown above on Additional failure modes that occur more rarely: Increase the `^10` to `^1000` or so to guarantee failure. Bisect finds: https://gist.github.com/c04a40f14712ce5a67dc171f87d3bcdb However: This is Rakudo version 2017.07-136-gda4a0f50a built on MoarVM version |
From @smlsAlso notable is that multiple iterations somehow see the same value for `$i` (as observed in the output listing above). I've sumbitted a separate issue for that (RT #131871), because the Capture-lookup bug of the current issue occurs even when removing the `$i`. |
From @smlsHeh, on further thought, they may be the same issue after all. In `/(...) { ... $i ... $0 ... }`, both the $i and the So it might be a general problem with the way that *code blocks inside regexes* access outer lexicals. (It doesn't happen with code blocks *outside* of regexes, and as the other ticket demonstrates, also doesn't happen inside the regex-portion of regexes.) |
From @dogbert17On Wed, 09 Aug 2017 13:32:58 -0700, smls75@gmail.com wrote:
It was initially broken with commit (2016-08-03) rakudo/rakudo@08e39ee |
The RT System itself - Status changed from 'new' to 'open' |
Migrated from rt.perl.org#131870 (status was 'open')
Searchable as RT131870$
The text was updated successfully, but these errors were encountered: