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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> 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).

You're right, poll_keyboard() already does something similar. However
poll_keyboard() explicitly deals with the keyboard input, whereas
al_lock/al_unlock() is supposed to deal only with threads and callbacks and
not interfere with input. If we took this path, I think we should also delay
the mouse mickey updates, no ?

--
Eric Botcazou