>I think the best answer is to do the second tier threading in
>userspace (best would be in glibc).
Do any systems that do mixed user/kernel threads work well? I've heard
nightmares about Solaris' threading system, with the complication of
hybrid threads as the prime culprit.
>The kernel folks have some good points about doing it the kernel but
>seem to have a mental block as to why you'd *ever* want hundreds of
>threads in a single app.
Yep, I've heard that too. I agree in principle - if you can avoid
having hundreds of threads, that's good. But it's really hard to
always rewrite your code to not use threads, and in the long run I
think the OS should do that work in most cases, not me.
Apache is an interesting compromise here. Multi-threaded, but careful
pooling to deal with OS limitations.
To be honest, I'm in over my head here. I don't know enough about
native threads implementations to really comment. I've heard lots of
stories of Linux native threads Java not scaling very well, and I know
that the Linux developers have generally not given a very high
priority to threading. Combine that with newer versions of Java
relying on the OS' threads, and it seems like we might have a train
wreck coming. Some work now might avert that.
Anyone else want to chime in?
BTW, one last JavaOne tidbit - I met the guy at Volano who's done all
the VolanoMark benchmarks over the years. Friendly chap, I thanked him
for all his benchmarking work. He told me they just recently switched
from Solaris x86 to Linux for their own use, I think because one of
the VMs (IBM?) finally could handle their load.
[EMAIL PROTECTED]
. . . . . . . . http://www.media.mit.edu/~nelson/
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
