lucadestudios team mailing list archive

[Luke Benstead <kazade@xxxxxxxxx>]

Hi guys,

OK I'm thinking aloud (well kinda) here so feel free to shoot me down.

The way I see it, we have at least two components that required
threading: networking and physics. Now, preferably the caller of each
of these APIs won't need to know about the threads, they just get
notified when things happen (a packet is received, my spaceship
crashed whatever). However, the system needs a way to register for
these notifications in a type safe way. For at least these two APIs we
can abstract this pattern away into the following (bad ascii art
follows)

      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 way, the caller doesn't have to worry about thread safety, and
everything ticks along. This can also be applied to other areas (the
GUI, the entity queue, whatever) so I might see if I can come up with
a templated solution.

Anyone have any other ideas, comments, etc. etc. ?

Luke.