Just another Perl shrine | |
PerlMonks |
Re^3: Score: Perl 1, Ruby 0by BrowserUk (Patriarch) |
on Feb 22, 2006 at 04:15 UTC ( [id://531869]=note: print w/replies, xml ) | Need Help?? |
it appears to be a hardcoded value. Which is a bit puzzling, given Win32's preference for threading vs. forking. The limit represents 1088 stateful threads per process, but threads do not have to be, and frequently are not stateful. At the C level, you can easily run 2000+ threads per process if they are not stateful. And remember this is concurrent. You can create fast-lived, do & die threads by the bucket load if that is what the design calls for. Also, many of the things you might consider spawning a thread for, like waiting for IO, there is no need for a separate thread as you can use asyncIO. You supply a callback on the read or write and let the OS call you back when it completes. I've seen a server application that could handle very high numbers of concurrent connections written this way, that only used 2 threads. I agree with you that 120 threads is more than enough from Perl, given the inherent weight of iThreads. For most purposes, I'd advocate using a mere handful of long running threads rather than zillions of short lived. It just makes best use of the resources available. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In Section
Meditations
|
|