[MUD-Dev] Sockets

[Chris Gray]

[Jon A. Lambert:]

> 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.
> 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.

Why do you assume that a non-threaded MUD that is using poll/select
will actually be doing polling? There have been lots of techniques
discussed, none of which do actual polling. I don't recall any of the
dev-mud versions using polling (I'm quite sure mine doesn't). The
name 'poll' can be quite misleading. Semantically it is very close to
the WIN32 WaitForMultipleObjects - it wakes up when any of the fd's
is active, or when the time limit expires. If the time limit is set
based on needed MUD events, then there is no polling.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


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