On 09-Jun-2000 Avi Cherry wrote:
> >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?
> >Or even one that would significantly benefit from hundreds of threads?
>
> Easy. How about any sort of stateful server? IRC. FTP. Whatever.
> While the UNIX way of doing this is with select(), and fork()
> generally, in Java, you create a thread for each connection that you
> want to manage. It makes it MUCH simpler to program. You can easily
> open up a few hundred connections in an IRC server.
IRC requires one connection to somehow pass information to the others,
not (I know zilch about IRC). OK, there the thread model gives you
shared memory without setting it up. FTP? I rather have each
connection handled by a separate process, it makes it a lot
more reliable (Windows has a DoS attack against SMB connections,
where one misbehaving client can zap the whole SMB subsystem,
which I believe runs as a set of kernel threads). One down,
all go. Security is a lot better with separate address spaces:
each connection runs with user privileges, which is rather
difficult to achieve with a threaded FTP server, I think.
Windows is dependent on threads for decent server performance, and
even there one would never start "hundreds" of threads (the box
just bogs down and never recovers), but one uses a small number
of threads serving many sockets per thread.
Seriously, "hundreds" of threads in _Java_, the acknowledged speed-demon
of languages?
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
