On Mon, 11 Mar 2002, Stephen Pair wrote:

> > I also did this in the first version of my network library.
> >
> > But, you may be better off not multithreading, but rather
> > scanning each socket. Multithreading is semi-expensive on
> > squeak.. Lightweight, but it may be faster to, for example,
> > have one thread scan all of the sockets than try to trust
> > multithreading like this.
> >
> > Scott
>
> Assuming that you're talking about Squeak processes (and not OS
> threads), why do you believe that scanning sockets would be any faster
> than the VM scanning through processes looking for the next one that's
> ready to run?  I've had the best success (performance and design wise)

Because in my case each time a line of data came in one socket, I need to
alter it and send it out the other sockets. Thus, I wished to avoid the
contention of several processes trying to write and read from the same
queues.  Unlike Comanche, my connections are extreemely dependent.

> having one process accepting sockets and forking a new process to handle
> each socket as it is accepted.  This is the way Comanche has always
> worked.
>
> - Stephen
>
>

--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.