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
regex optimization affected by threads #9373
Comments
From jgmyers@proofpoint.comCreated by jgmyers@pong.us.proofpoint.comThe following test program shows a regular expression running quickly This reproduces under 5.10.0 as well. use threads; sub start_thread { my $buffer = '.' x 15000; if ($ARGV[0]) { Perl Info
|
From @iabynOn Tue, Jun 10, 2008 at 03:22:40PM -0700, John Gardiner Myers wrote:
When the thread is created and the regex is dup'ed, the The place where it might get set to something, Perl_regdupe_internal(), This is a bit outside my area of expertise. -- |
The RT System itself - Status changed from 'new' to 'open' |
We were only handling "synthetic start classes", not ones that are in the program itself, because those dont have an entry in the data array. So after copying the program after ruling out that the regstclass is synthetic we can assume that if its non-null it points into the program itself, and simply set it up the copy accordingly. Fixes #9373
thx! We get burned by this once a year as some feature that works perfectly single-threaded, blows up and takes up to several minutes when multi-threaded - thereby causing our watchdog to kill the service. It's completely non-intuitive and often takes quite a while to realize is the same bug since our app can run in both modes |
We were only handling "synthetic start classes", not ones that are in the program itself, because those dont have an entry in the data array. So after copying the program after ruling out that the regstclass is synthetic we can assume that if its non-null it points into the program itself, and simply set it up the copy accordingly. Fixes #9373
@todd-richmond #20656 should backport nicely IMO. It looks like this goes back to the beginning of threads. :-( Sorry it took so long to realize it was easily fixable. |
We were only handling "synthetic start classes", not ones that are in the program itself, because those dont have an entry in the data array. So after copying the program after ruling out that the regstclass is synthetic we can assume that if its non-null it points into the program itself, and simply set it up the copy accordingly. Fixes Perl#9373
We were only handling "synthetic start classes", not ones that are in the program itself, because those dont have an entry in the data array. So after copying the program after ruling out that the regstclass is synthetic we can assume that if its non-null it points into the program itself, and simply set it up the copy accordingly. Fixes Perl#9373
We were only handling "synthetic start classes", not ones that are in the program itself, because those dont have an entry in the data array. So after copying the program after ruling out that the regstclass is synthetic we can assume that if its non-null it points into the program itself, and simply set it up the copy accordingly. Fixes Perl#9373
Migrated from rt.perl.org#55600 (status was 'open')
Searchable as RT55600$
The text was updated successfully, but these errors were encountered: