Re^2: Score: Perl 1, Ruby 0

Thnx for the great info. I went stomping around the 5.8.7 source, and located the TlsAlloc() call (in the ALLOC_THREAD_KEY macro), but can't find more than a couple instances of ALLOC_THREAD_KEY being called...probably requires a hard-core debug effort to track down why/where so many are needed. (Unless any of the p5p'ers out there might shed some light ?)

I also googled about to see if I could find a registry key to tweak Win32's limit, but wo/ luck, it appears to be a hardcoded value.

Which is a bit puzzling, given Win32's preference for threading vs. forking. Considering that dual core CPU laptops are now available, and both AMD and Intel have announced quadcores for next year, I'd hope hardcoding this value might need re-examination, if they intend to play in the high end server market. (And the constant's name seems backwards: TLS_MINIMUM_AVAILABLE actually means the maximum available). Guess I'll have to wait and see what Vista brings.

I guess one can point fingers of shame at both Perl and Win32. Fortunately, 120 threads is sufficient for my needs on Win32 at present.

Comment on Re^2: Score: Perl 1, Ruby 0

Replies are listed 'Best First'.
Re^3: Score: Perl 1, Ruby 0 by BrowserUk (Patriarch) on Feb 22, 2006 at 08:40 UTC
I went stomping around the 5.8.7 source, and located the TlsAlloc() call (in the ALLOC_THREAD_KEY macro), but can't find more than a couple instances of ALLOC_THREAD_KEY being called...probably requires a hard-core debug effort to track down why/where so many are needed. I've been down that route before and become very lost in the myriad definition and redefinitions of everything that surrounds the whole `PERL_GET_CONTEXT/Perl_get_context/aTHX` stuff. I just tried again and got royally stuffed trying unwind the macros. Compilers are good at doing that--people (at least this person) ain't. Upshot: Took a different tack and queried information about the TLS indexes from the OS from with in the thread itself, and whatever storage is being run out of, it isn't TLS! 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.	[reply] [d/l]
Re^3: Score: Perl 1, Ruby 0 by BrowserUk (Patriarch) on Feb 22, 2006 at 04:15 UTC
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.	[reply]


P is for Practical
	PerlMonks