Re: singe thread per connection

Peter Duniho wrote:

On 32-bit Windows, the theoretical maximum number of threads per process is about 2000, with the practical maximum somewhat lower, and performance suffering significantly before that. Unix/Linux would be different...threads are much lighter-weight constructs on those OSs.

Hmm that's interesting -- I wasn't aware of this 2000 limit. FWIW, in a
quick test I can start up about 5,600 threads in XP before I get a
"Cannot start new native thread" error, but I'd concede that's more or
less a limit within the order you say. Although it's a bit bonkers
to want so many threads, it's also kind of disappointing that you
absolutelty can't. I guess Windows uses a bit more memory than you'd
think for each thread control/environment block.

I'm also introgued by another thing: if I understand you correctly,
you're saying that there's a performance difference between having
X threads all from one process and having X threads distributed
across various processes. I thought that the Windows scheduler at least
was agnostic as to which process a thread was from: it just scheduled at
the thread level. The Thread Scheduling chapter in "Microsoft Windows
Internals" (4th ed), for example, describes a dispatcher database
consisting of the list of *threads* ready to run at each priority
level. I suppose that threads distributed over different OS processes
are maybe more likely to have different priority levels (since their
processes are set different base priorities), but other than that,
do you know of any reason for a performance difference for X threads
in a process vs X threads across the whole system?

Of course, I'm not aware of any requirement that a Java thread be implemented exactly as an OS thread. So OS limitations may or may not apply in Java.

In principle, there's no obligation for 1 Java thread = 1 native thread.
In practice, I think practically all JVMs use native threads if they're
available. Sun's VM certainly used to have an option for "green
threads" (threads emulated within Java). But assuming it's still even
available, I suspect that maintaining and improving the green threads
model hasn't exactly been a priority for Sun, and suspect it's
essentially not used very much. Oother VMs (e.g. I suspect Acorn's
VM for RISC OS) have been forced to implement "green" threads due to
lack of thread support from the OS.

But my comment wasn't directed at the question of whether one would "get away with it". I was commenting on what would be a _good_ approach. I have the impression you agree with me on that point. :)

Oh yes, definitely. I was just thinking that "opening 500 simultaneous
telnet connections" sounded suspiciously like "need to knock something
up to interface with some legacy system for internal use" rather
than "need to spend a long time developing a well-designed app for
end users". NIO tends to require an investment in time when you first
start using it (though if you need performance, it pays off).

Neil
.