[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

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

[Full Header] [Plain Text]
From: Oliver Jowett <oliver@jowett.manawatu.planet.co.nz>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 21 Jul 1998 09:47:48 +1200 (NZST)
References: [1]
Organization: Kanga.Nu
On Mon, 20 Jul 1998 s001gmu@nova.wright.edu wrote:

> On Sat, 18 Jul 1998 oliver@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.

-O