lucadestudios team mailing list archive

[Sean Hodges <seanhodges@xxxxxxxxxxxxxx>]

On Tuesday 24 February 2009 17:18:11 Luke Benstead wrote:
> 
>       ExternalEvent
>                |
>                |
> 
>        APIInterface   <---------------->  InternalEvent
> <------------> APIThread
> -  update()
> - registerCallback(ExternalEvent, Callback)
> - unregisterCallback(ExternalEvent, Callbac)
> 
> 
> Basically, an "internal event" is something that the API (in the
> calling thread) needs to know about, but does not necessarily need to
> tell anyone else. An "external event" is something that the caller
> might want to register for a notification about, an internal event MAY
> map to an external event, but not all the time. The "api thread" does
> all the work, and queues up internal events for processing, when the
> update() function is called, these queued events are processed and the
> callbacks are fired.

This looks quite similar to the publish/subscribe pattern used in DBUS, with 
one thread acting as a message bus for the events that are passed through.

One thing I wasn't clear on with the design is where the callback would be 
processed? If it's in the API thread then we would have to be careful about 
intensive tasks taking over the thread and causing other events to queue for 
ages. On the other hand, delegating back to the owner of the callback might be 
difficult if that thread is busy doing something else...

For the record, DBUS passes the event back to the callback owner, and as such 
it relies on a gobject event loop to be running (which takes over the thread). 
This obviously dictates how your callback class is structured, and takes 
control away from your thread.

Cheers,

Sean