[MUD-Dev] Re: [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine

[oliver at jowett.manawatu.planet.co.nz]

On Sat, 18 Jul 1998, Todd Lair wrote:

> Each player and the master socket, gets its own individual
> event associated with it.  When this type of event ripens,
> it means that this single socket needs polling to see if it
> has input, output, or an exception.  read: not all the
> sockets, but the one.  My question again, is how should I
> go about determining the read, write, exception status. 
> Currently, I'm using select, setting a single bit in each
> of the fd_sets for the descriptor.  This doesn't seem ideal
> to me, since over time, the descriptors get higher in
> number value, and the select call has to scan the fd_sets
> to see where the single bit is set in each of the sets.
> 
> I was wondering if I should just use recv (possibly passing
> the the peek parameter) to determine the status of the
> descriptor that needs to polled.  I was wondering what
> returns I need to worry about, and if this would be a much
> more efficient method opposed to the select call on the
> single descriptor.

I assume that the reason you're checking individual sockets via events is
due to some command-parsing requirement, eg. commands won't be processed
until N seconds in the future after some action by a player.

Why not move this to a separate layer? At the lowest level, select() on
ALL sockets with a timeout equal to the time to next pending event. When
input arrives, read and buffer; when output is possible, write from a
buffer; when exceptions occur, set an appropriate flag. Loop back and
repeat the select. Then when the event actually goes off, you check and
modify the buffers.

Think of it as a wrapper around recv() et al. to avoid making many "real" 
syscalls. The implementation of the wrapper could be different - the same
high-level model could apply to, say, using a pool of threads to handle
I/O, I suspect. 

-O