🚀 go-pugleaf

Eric Hodges wrote:
> 
> Mark Frazier wrote:
> >
> > > The xware.net.Selector class provides an event-driven mechanism for
> > > handling input from
> > > multiple sockets. It is ideal for writing server like Java applets or
> > > applications. It can be used
> > > on both the client or server side of your sockets based interface.
> >
> > Thanks for this.
> >
> > However, isn't more "java like" to take the approach of
> > running every socket in a new thread? I've done this in
> > Java servers. You start up a Java server socket, and everytime
> > you get a connection, you run a new thread which is a class
> > that serves only that socket. The code is pretty trivial.
> 
> Yeah, I'm not sure why anyone would want to go back to select().  That
> always seemed like a hack to deal with asynchronous notification in a
> single threaded environment.

Do you have one thread doing the accept, then creating other threads to
handle socket communications?  Check out Comer/Stevens for problems with
this.  Basically, your code may drop a connection request because
starting threads may be too expensive.  Why not have each thread do an
accept request with a monitor thread starting more threads when few are
actually waiting for accepts?

I too find the use of threads for this purpose to be easier in Java, but
one has to watch for thread-safe code, i.e. synchronization issues.

Incidentally, I find the select is a UNIX hack.  The VMS sys$wflor seems
to be a bit cleaner, but the archeciture of the program is roughly the
same as using the select.

Chuck McCrobie (** MAD VAX **)

-- 
ALL OPINIONS DO NOT NECESSARILY REFLECT THOSE OF MY EMPLOYER.