>> I'm not one of the kernel folk, but can you give me an example of
>> an application that would be impossible without hundreds of threads?
Many of these examples have a common theme - lots of network I/O to
different places. We've learned from web servers that it's actually
better if you multiplex your own I/O via select() rather than using
fork(), but the reality is it's a big pain in the neck to write code
that way. And green threads, in many ways, are just a thread
abstraction on top of the select() magic that you'd have to write
special purpose.
>A RMI server on the net. One of our servers is handling now tens of
>connections, expected at some time to be hundreds. At this time we are
>using Solaris for Intel w/native threads.
Sun's RMI is worse than that. It's not just one thread per other
computer, it's one thread per simultaneous message. At least back in
JDK 1.1, if you have two RMI calls active to another computer, you get
two sockets, two threads, two everything. It gets ugly.
Again, it's possible to fix this, but it's a lot of work. Wouldn't it
be grand if you could just rely on the JVM to handle it for you? With
green threads, you mostly could, at least up to hundreds of threads. I
worry with native threads the limit is more like tens.
[EMAIL PROTECTED]
. . . . . . . . http://www.media.mit.edu/~nelson/
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
