Oliver Jowett oliver at jowett.manawatu.planet.co.nz
Tue Jul 21 09:47:48 New Zealand Standard Time 1998

On Mon, 20 Jul 1998 s001gmu at nova.wright.edu wrote:

> On Sat, 18 Jul 1998 oliver at jowett.manawatu.planet.co.nz wrote:
> > 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.

I'm not quite clear about how your timing system works - it sounds like a
"tick-based" system which has a much finer (and externally-run, although
that shouldn't affect much) timing resolution? 

If you're working with a single thread - how do events get added without
either I/O occuring or an event happening first? Signals, I guess. 
Personally I avoid using signals for anything short of exceptional
external circumstances where possible :)

With multiple threads I'm not quite sure why you'd want to have the event
system timing tied into I/O waits anyway.


More information about the MUD-Dev mailing list