Re: Event based system

["Adam D. Moss" <adam@gimp.org>]

"Miguel A. Osorio" wrote:
>         Great, I'd really enjoy to take a look at it; but still, could you
> point out any article or paper, or whatever, on the basics of event
> system design and principles - I'm still quite a novice on such matters.

I'm afraid I don't have any references.  The current design such
as it is just came together after experience with X11's events,
GLIB/GTK's signals, java's producers/consumers and a monsterously
unwieldy event system I used for my last big aborted game (it's
good to actually learn from mistakes).  I don't pretend that it's
a miracle of computer science, but it's supposed to serve the
intended function and help me avoid the usage traps I usually fall
into.

> > I issue LOTS of types of events from LOTS of triggers all over the
> > place without knowing if anyone is listening for that specific event
> > type; the event system sorts it out quickly, and the event payload is
> > a void* whose contents are agreed between trigger and listener for a
> > particular event type, so I don't take a hit from copying around a
> > chunk of payload data for no reason but this does also imply that
> > event delivery is sychronous so I can cheerfully not have to guarantee
> > that the payload's lifetime extends beyond event delivery (it can be,
> > and usually is, a structure just sitting on the stack).  If the
> > listener wants to preserve a copy of the payload data then it can take
> > a copy, and it already knows how.
> 
>         Yes, yes, I was thinking of something quite like that, but does it
> *have* to be synchronous to work?

No, I don't think so -- you just have to shift ownership of the event
payload to the event system or listener rather than the trigger, give
each listener's queue its own copy (or refcount) and make sure that
there are no flapping pointers in the payload (this does restrict what
you can represent with it and where you allocate it from).

Even when keeping the actual event delivery synchronous, there's
nothing stopping the listener's receiver function from doing nothing
except copying it into a listener-private queue for later processing
(for some purposes this sort of behaviour is going to have to be
necessary, such as to defer the destruction of trigger/listener
while their tables are still being walked -- I'm looking into how
easy it is to encourge usage patterns which just avoid such
yuckiness, rather than over-engineer around it [speaking from painful
experience]).

The enforced synchronicity is meant to be a feature rather than a
bug, though.  I fell into too many poorly-defined-memory-ownership
traps with my last attempt (and walked the avenue of pain which
is id-to-pointer and pointer-to-id hashes to try to avoid the
dreaded dangling references).  Now listeners throw events with event
structures which they are usually building for their own use anyway,
and typically on the stack.

--Adam
-- 
Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
"You could make a mince pie mountain and
carve yourself a lair inside to live in."