[DGD] Fw: Re: callout cantrip

[bart at wotf.org]

Bah, as usual, sent this from the wrong email addy :P

---------- Forwarded Message -----------
From: "Bart van Leeuwen" <bart at bartsplace.net>
To: "All about Dworkin's Game Driver" <dgd at dworkin.nl>
Sent: Sat, 14 Mar 2009 12:06:25 +0100
Subject: Re: [DGD] callout cantrip

On Sat, 14 Mar 2009 02:16:49 -0700, Shentino wrote
> Ok, so I was sitting back for a bit, experimenting with callouts,
>  and I suddenly had the bright idea of trying to pass a callout its 
> callout handle as an argument.
> 
> Naturally, owing to causality, not very straightforward.
> 
> Apparently arguments on pending callouts share the object's 
> dataspace, so what I was able to do was pass a one element array,
>  have the callout scheduled, and then modify the array in place ala 
> TLS/call_trace, thus giving the callout information on what its 
> handle was. ___________________________________________

I've used this trick before for another purpose, it works really well.

Lets say you want a daemon like object to distribute events which roughly
works as follows:

objects can register themselves to the daemon as 'interested' in an event
objects can send a notification to the daemon that an event has occured, which
will then be sent to all objects that are 'interested'.

Now, the obvious solution is to simply loop through all interested objects and
call the event notification function in them, but this has a few problems:

- This all happens in a single execution round/thread
- A runtime error in an event handler will terminate the loop unless caught.

So, a slightly more advanced solution might be desirable.

The solution I am using is as follows:

When the event occurs and the daemon gets called, it starts with doing a (0
delay) call_out to itself with as argument an array with a few elements, the
'next' object that shoud be processed, the event this concerns, and possible
arguments to the event.

Once this call_out is started, the daemon starts a loop that first gets the
object from the the array that was also passed to the call_out (lets call this
the 'current' object), then determines if/what object should be handled after
that one, changes the array accordingly, and then calls the event handler in
the 'current' object.

Now, it keeps looping there until it is out of time (it monitors ticks used)
or until an error occurs. (each time the loop runs it starts with getting the
'current' object from the array and then changing the array to point to the
next object before actually calling the event handler)

When its out of time or an error occured, the call_out it started earlier will
ensure that all interested objects will get the event notification still.

As an aside, gurbalib's event daemon is being changed to a somewhat similar
implementation.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/
------- End of Forwarded Message -------


--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/