in reply to Re^2: Score: Perl 1, Ruby 0
in thread Score: Perl 1, Ruby 0
This code doesn't give the intended results.
Who's (and what) intended purpose? It certainly served my intended purpose--that of discovering the limit of concurrent threads runnable using the Perl executable when built with the default Win32 configration.
I'm still limited as to how many threads I can kick off.
If the former, the snippet was not intended to, and could not, bypass the inherent limitations of the Perl executable.
If the latter, in most cases you should probably think again about your design. If you really believe that you have an application that does benefit from more than 120 concurrent iThreads, then see point 2.
That said, that post only addresses the how, not the why. To usefully make use of more than 120 concurrent iThreads requires much more than just changing the limit. It also requires that you adopt some very specific coding practices to avoid or work around other limitations inherent in the iThreads architecture.
These practices are neither intuative, nor what would be readily recognised as standard Perl working practice. They are described, piecemeal, across a whole bunch of posts (by me and others, notably zentara,jdhedden & renodino) here at PM, but to my knowledge there is no one place here or elsewhere that brings all the details together in a comprehensive reference. In part, because I don't think that anyone has really done enough work in multi-cpu environments to have yet tied down what best working practice should be.
If you still believe you have an application that would benefit from running large numbers of concurrent ithreads, if you were to post a description of that problem, you may well get further advise on implementing it. Along with advice on the possible alternatives to ithreads for achieving your goal.
|
|---|