Re: [AD] Proposal for an input model

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Usually, users will call al_poll_input once per frame,
> and if frame rate is good, most applications will not notice
> synchronous nature of these asynchronous callbacks in second case.

That's IMHO too optimistic: not every application is built on the model of a
game, with a single main loop controlling everything.

> Calling al_poll_input from input thread on platforms that can block
> until there is something to input is not good, because al_poll_input
> is callable by user and user may call it when there is nothing to
> read.

al_poll_input() won't of course block even on these platforms, but it may be
nevertheless called by the input thread if the thread has been informed that
something has changed.

> For such platforms it would be better to have noop
> al_poll_input (maybe not exactly noop, if it returns something, but it
> should not try to read input state) and update input state from input
> thread.

Do you mean if the input thread is up and running, that is if the user has
registered callbacks ? I agree, switching to the asynchronous input model as
soon as one callback has been registered may be the right thing to do, and
in this case, yes, al_poll_input() will only make sure the input thread has
completed its current update (if any) and return. But that's IMHO purely a
platform-specific design decision.

> If timers will stay in Allegro, and any Allegro functions may be
> called from timer callback, then we may add timer callback that will
> call al_poll_input periodically.  Though, it will add dependency
> between input and timer.  IMHO, this is not necessary.

I agree: timers and input should stay different things.

> We may use implicit polling if al_poll_input was not called and add
> counter to do this polling only after some number of input related
> functions were called without al_poll_input, this counter will be reset in
> al_poll_input.

A weird idea :-)

> BTW, it might be possible to have input thread in X (with some
> limitations), but I think it is not possible to have it block when there
> is no data with core Xlib functions.

Do you mean an input thread different from the window event thread ?
Couldn't you use one single blocking thread for all X events, using
XNextEvent() or any other routines that wait for events ?

More generally, couldn't the internal pthread framework be modified to allow
threads to block ? I understand that, since the initial implementation was
using signals, the registered routines were not allowed to block and the
pthread framework had to follow and thus poll. Do you plan to get rid of
this limitation ?

--
Eric Botcazou
ebotcazou@xxxxxxxxxx