Juergen Kreileder <[EMAIL PROTECTED]> writes:
> 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.
This is the same kind of argument that the Linux kernel folks use --
the status quo is good enough, they say, and anyone who wants to do
anything outside of their idea of what the appropriate regime for threads
is must be crazy.
Apart from the fact that nonblocking I/O won't be part of the JDK until
at least 1.4, there are plenty of good reasons to expect threads to
perform at least well enough to support *some* server applications:
- Threads are part of the Java language. Unlike languages such
as C, compilers and runtime environments can deal intelligently
with multithreaded applications. Why not use them?
- I believe quite strongly that writing code using threads is easier
than using event-driven programming and nonblocking I/O.
- Event-driven programming requires that all libraries and "third party"
code in the application also be nonblocking. If you write an application
using a small number of threads, and call into a library which blocks,
your threads are effectively "lost" and you must create more of them.
Porting "legacy" code to use nonblocking interfaces is not easy in
general. Most existing Java libraries assume threads -- again, since
they are built into the language.
- Debugging event-driven applications is hard, since it's difficult to
trace the control flow of a given chain of related events (e.g.
the processing stages of data coming in on a particular socket).
You are right that Java programmers tend to use many threads. They are,
after all, supported directly by the language, and the JDK libraries
don't currently give you any way of doing event-driven programming instead.
Hence - threads should probably be something that the Java-Linux community
cares about, regardless of whether programmers "should be" implementing
things that way.
Matt Welsh
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
