On Mon, Jun 12, 2000 at 09:36:27AM -0700, Matt Welsh wrote:
>
> 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.
I don't think anyone is arguing that high thread counts are always
wrong or that the current implementation is the best of all worlds.
But the reality of system architecture sometimes intrudes on our
treasured abstractions - this is especially true with Java, whose
management of memory, threads, and other resources doesn't always mesh
well with the ugly realities of running efficiently and scalably on
todays architectures.
Yes, the Linux kernel can do better and Java implementations can do
better - I don't disagree with your assertions of how well things
*should* work. If only we could talk the code and the underlying
architectures into working better, we'd be there :-). Short of that,
recognizing how to deal with current shortcomings and current system
architecture limitations can make the difference between successfully
using Java and giving up on it.
Nathan
> 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]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
