[EMAIL PROTECTED] (Nelson Minar) writes:
> 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.
Still, green threads do not work very well (see the first paper on my website
for details) -- and they cannot take advantage of multiple processors on an
SMP. You would think that native threads are the answer but they are
extremely expensive on Linux. (Solaris native threads are better but
still don't scale up to thousands.)
In either case we need to get Linux native threads to scale much better
than they do now. This might mean convincing the kernel developers that
scaling up to thousands of threads is important -- does anyone have a
reading on what the kernel folks think about the current situation? In
the past I believe they didn't think this was an important problem to solve.
> 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.
I thought that Sun's RMI did fairly aggressive thread and socket sharing.
NinjaRMI didn't do this because it complicated the design and made it
hard to do pluggable transport layers.
Matt Welsh
http://www.cs.berkeley.edu/~mdw
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
