in reply to Re^11: Consumes memory then crashs
in thread Consumes memory then crashs
on the latest StrawberryAh! That's built with the gcc runtime isn't it!
Yes. If you insist, here's some uniq'd output from a freshly installed ActivePerl 5.14.2 which they tell me is built with VisualStudio:
$ uniq -c outfile | head -n25 682 Thread 2 1 Thread 2Thread 3 681 Thread 3 1 Thread 3Thread 4 681 Thread 4 1 Thread 4Thread 5 681 Thread 5 1 Thread 5Thread 1 681 Thread 1 1 Thread 1Thread 6 681 Thread 6 1 Thread 6Thread 7 681 Thread 7 1 Thread 7Thread 8 681 Thread 8 1 Thread 8Thread 9 681 Thread 9 1 Thread 9Thread 10 629 Thread 10 1 ThThread 11 629 Thread 11 1 ThThread 12 629 Thread 12 1 ThThread 13 629 Thread 13
If Perl's threading primitives' semantics were broken unless compiled with a runtime that <<10% of the installed Perls use, I'd still call Perl broken. If I can reproduce the bug on each an every Perl I look at though nobody seems to have complained about the primitives you use being buggy, chances are your Perl code is broken.
I don't know which it is, but it remains that I haven't seen a reliable threaded implementation yet. I for one would centralize the printing and use another Queue to feed back the results from the threads as at least the queue locking seems (as far as I've looked which is not very deep at all) to be working. But then again, why? I don't get the resistance against POE which fits on a floppy disk and is some 20kLOC without POD when common threading implementations are on the same order of magnitude (of rather more complex C code at that) and 20 MB of RAM are insignificant to you.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^13: Consumes memory then crashs
by BrowserUk (Patriarch) on Mar 26, 2012 at 20:59 UTC | |
by mbethke (Hermit) on Mar 26, 2012 at 21:05 UTC | |
by BrowserUk (Patriarch) on Mar 26, 2012 at 21:18 UTC |