Re: [AD] Proposal for an input model

[Michael Bukin <M.A.Bukin@xxxxxxxxxx>]

"Eric Botcazou" <ebotcazou@xxxxxxxxxx> writes:

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

I can not think of any example where asynchronous framework on top of
polled input will give significant benefits over user controlled
polling, maybe impicit polling.

Below are some unsorted ideas.

There might be entity (let's call it input stream) that collects all
input from specific device.  For some platforms input from device is
placed to this stream when user requests it by
al_poll_input([AL_STREAM?]), for other platforms device driver will be
running in its own thread and will place data into input stream when
it is available.  Function which is used to place data to stream may
test for registered callbacks and call them if applicable.  User may
also read stream state using supplied functions, read events buffered
in stream, etc.  With this framework, there will be difference between
polled and asynchronous driver types.  If polled driver is not polled
periodically, it will not call asynchronous callback, while async
driver will always call them.  We'll need to poll by timer, or have
this inconsistency in behaviour between different platforms.  Anyway,
how useful it is to have all input handled by callbacks, without
single al_key_pressed() or similar?  Most programs will be happy with
al_readkey() and al_key_pressed() (there are better names for sure).

Maybe we should require user to poll, in order to get callbacks
working on all platforms.  As a result, on some platforms callbacks
will be synchronous and will not work in pure callback based
application (with no function calls to allow polling).  IMHO, it will
simplify things a lot and it will be easy to make things working on
every platform, yet allow to add asynchrnous callback later.

We may have one entity, where all input and event sources, and
callback generators are registered.  User may poll this entity for
changes, and it will call callbacks when needed, or user thread may
block in this 'thing', until any event arrives (keyboard, mouse,
switch in/out, etc).  User may register callbacks for specific events,
or not register callbacks and parse events returned by this 'thing'
(how to call it? maybe 'noname').

It's a mess, I know.  This topic is too vague for making good design
which will fit all platforms.  Personally, I'd prefer something which
is simple to implement and simple enough to use.  I don't think it
will be any harder than current Allegro input model.  At most, it may
be necessary to pass around handle returned by initialise_some_device,
or something similar.

> 
> 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 ?

Oh, yes, XNextEvent (how could I forget it?).  Then it might be
possible to have blocking :-)

> 
> 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 ?

It might be possible, if blocked thread does not block while accessing
Display handle which is used in other threads, i.e. it should allow
other threads to access their Display handles (if these handles are
different from that of input thread) and allow them to work as usual.

I'd rather use fork and IPC, which will be much simpler to use
(implement and debug), and will be more portable.  Callbacks may be
done with signals, though it will limit possible usage of signals in
the program.  Parent program forks user thread and other threads, then
watches for death of any process and closes other processes in such
case.  This would be relatively easy, if only Xlib was supported, and
no other drivers.  That's all IMHO, of course, and it might be wrong
too, because nothing is implemented yet.
(Everyone needs a dream... :-)

Not I'll wait for others to point me to some obvious flaw in these
ideas :-)

-- 
Michael Bukin