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

[s001gmu at nova.wright.edu]

On Sat, 18 Jul 1998 oliver at jowett.manawatu.planet.co.nz wrote:

> On Sat, 18 Jul 1998, Todd Lair wrote:

[each socket gets an event that triggers a select on its FD]
[recv concerns]
 
> 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.

Either a parsing requirement, or an attempt to avoid the CPU spinning it's
wheels whilst idle.  In effect, it is a polling loop, just implemented
through an event queue, with some (non-wasted) delay time betwixt loops.
Make sure to build your write FD_SET intelligently.  Don't add FDs that
don't have pending output. :) 

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

This works nicely, as long as you have a tick based event queue.  The
model I use is based on the system clock, and uses a linked list as the
main structure.  With one cpu, it is physically quite impossible to
schedule two events at exactly the same time (and with multiple it is
quite unlikely), so I don't need any auxiliary linked lists to handle
collisions.  The problem is that my event driver sleeps until the next
event is scheduled to go off, OR another event is placed first in the
list.  If the later happens, not only would I have to wake up the event
driver, but I'd also have to interrupt the select, and then reschedule it
with a new timeout.  Granted, that's not very difficult (just include a
pipe in your read FD_SET and write to it when you wanna interrupt), but it
seems less elegant... it ties the event driver to the socket handler in a
rather nasty way.  The socket handler and event driver are not really
related to eachother, and shouldn't be tied together in that way.  Todd's
system shouldn't have a problem with it, though, as his socket handler
would only be taking advantage of a feature of his event driver (fixed,
known-length tick intervals).

-Greg