[DGD] Fw: Re: callout cantrip

[Shentino]

So you use the callout's arguments as a sort of "floating buffer"?

On Sat, Mar 14, 2009 at 4:07 AM, <bart at wotf.org> wrote:

> 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/
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>