Juergen Kreileder wrote:
> I still haven't seen one good argument for using thousands of threads
> except for working around Java's _current_ IO limitations and doing
> better on benchmarks which test work-arounds for these IO limitations.
>
If one uses Java's natural tools (no JNI/2nd-tier-server tricks), a RMI
server with thousands of connections would create thousands of threads.
As far as I know, the language does not provide alternatives to this.
So either Java supports well this scenario, or is unfit for the job.
I/O trickery is always possible, but I would opt to do it in C/C++, where
I have better natural tools such as select().
Now, I don't want to suggest that the tipical Java net app should/would
use that many threads, but the high water mark for net apps would push
it that way.
I humbly state that if we want to be able to recommend Java for net
programming w/o previous assesment of language I/O limits (as we do
recommend C/C++), we need to support thousands of threads or change
the internal definition (not for a single implementation/platform)
of tools such as RMI. The I/O limits then would be OS-dependent,
as with C/C++.
--
Diego Pons Pharos Consulting LLC
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
