[MUD-Dev] Sockets

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Jon A. Lambert" wrote:
> The common select/poll loop for non-blocking sockets that processes
> incoming, exceptions, reads, writes, and other mud processes is not
> very efficient.  Firstly setting up the parameters to select and checking
> the FD_SETs involved alone is probably higher overhead than threading.

This discussion is pretty useless as you don't assume anything about the
implementation of the MUD or the OS, but I don't believe that you will get
much from using threads anyway :). Assume 1000 fds and that setting or
checking one bit takes 100 cycles. That would give 200K, but computers of
today approach 1000GHz!  Switching between 1000 threads is going to cost
quite a bit, considering how badly this will trash the cache, all the
semaphore checking etc.  So basically, I don't see how threading could
possibly buy you much. I can't really see how it can win either, provided
the select() call is implemented in a reasonable fashion. Is this really the
main problem? Even if the select call spends 1000 cycles per FD you still
will burn less than 1% of your processor time? (assuming <10 selects per
second)

> Secondly if the poll time is too short you end up burning processor
> cycles in the poll loop for no good reason.  And if the time is to long
> you end up sleeping while your mud could be processing ripe events that
> are issued from other functions in the mud (assuming that not all your
> events are initiated immediately for user input).   Yes, some good
> implementations attempt to dynamically adjust the polling time depending
> on how active the server is/was.  Still there is enough overhead here
> to more than compensate for the overhead incurred through thread locks.

And I don't get this. There is no point in checking the input more often
than 1/4 the average lag time or something like that. Besides, you can stuff
that in a separate thread/process, which you would want to do in a large
scale system anyway. Then you can have a distributed pool of connection
processes feeding the main server.

> A threaded implementation will wake up "exactly" when data is ready on
> the I/O ports and "exactly" when data is ready for sending.

This is good?  This could mean a lot more switching, depending on the kind
of events your client produce. There is no point in reading more often than
the user will notice, and you can forget about the writing, if the buffer
fills up then the user is at loss anyway. I think you assume something about
the scheduler here as well... ;)

--
Ola Fosheim Groestad,Norway      http://www.stud.ifi.uio.no/~olag/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev