Re: [AD] Mini-synchronization API proposal for 4.1.x

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2002-04-03, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> > It works with both pthreads and SIGALRM.  What happens is
> > that if callbacks are disabled, any new callback 'events' are added to
> > the queue, which is completely flushed when callbacks are reenabled. I
> > don't know if that's good (what if the flushing takes too long?), but
> > it was easy to code :-)
> 
> I'm in the process of extending your code, but I came across a glitch: most
> callback events are uni-directional (from Allegro to user) so can easily be
> delayed, but two of them (keyboard_callback and keyboard_ucallback) are
> bi-directional.

Bugger.

> However, these two callbacks are a little bit different from the other ones
> (timer, low-level keyboard, mouse, switch) because they are called on
> already processed (high-level) data, so I think we could exclude them from
> the event pool and rename them 'filter' instead (keyboard_filter and
> keyboard_ufilter) with two #define in alcompat.h .

I meant to think about this before replying, and it seems I forgot,
sorry.  Now I've probably forgotten the subtleties :-)

Anyway, would it be bad to delay the call?  Let's see:

main thread     auxiliary thread
-----------     ----------------
lock
                key pressed:
                   want to call keyboard callback;
                   bleh, it's locked, stuff into queue
unlock
                flushing the queue:
                   lock;
                   call callback, retrieve return values then process;
                   unlock
doo doo doo     twiddle thumbs
-----------     ----------------

I'm being optimistic, but looks fine to me.  I also had a superficial
look at keyboard.c, and it seems feasible (poll_keyboard is doing much
the same thing, entering new keys into a buffer and delaying the state
updates).