[perl #131870] [CONC] Capture lookup inside regexes is not threadsafe

2017-08-09 Thread via RT
# New Ticket Created by Sam S. # Please include the string: [perl #131870] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131870 > When the same regex is used concurrently from multiple `start` threads, looking up already mat

[perl #131871] [CONC] [REGEX] Regex code block closing over lexical variable, is not threadsafe

2017-08-09 Thread via RT
# New Ticket Created by Sam S. # Please include the string: [perl #131871] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131871 > This bug was found as a side-effect of RT #131870, but might be a separate issue: ➜ awai

[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe

2017-08-09 Thread Sam S. via RT
Also 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`.

[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe

2017-08-09 Thread Sam S. via RT
Heh, on further thought, they may be the same issue after all. In `/(...) { ... $i ... $0 ... }`, both the $i and the $0 (or $/ rather) are outer lexicals from the point of view of the curly block, right? So it might be a general problem with the way that *code blocks inside regexes* access o