Re: [AD] Proposal for an input model

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

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

The asynchronous framework is not really on top of the polled input
(although that's how I described it) because the input drivers provide hooks
so that the input is really asynchronous once callbacks are registered. So
you can do whatever you want within the primary thread (including blocking)
while still receiving input.

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

IMHO we should definitely forget the timers.

> Maybe we should require user to poll, in order to get callbacks
> working on all platforms.

Horror ;-) Then we had better forget callbacks.

> This topic is too vague for making good design which will fit all
> platforms.

I don't think so: we have a working basis, that is our little Allegro 4.0
library.

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

Again the complexity is the same I think, and model 3 can be derived from
model 1 without too many efforts. I'm going to give it a try this week-end
with Allegro 4.0 on the platforms I have access to: DOS (trivial), Windows,
Linux, X11 and QNX.

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

Why would there be several Display objects ? Can't a single Display object
be shared between several threads ? However, the problem you mention has
clearly to be taken into account.

> I'd rather use fork and IPC, which will be much simpler to use
> (implement and debug), and will be more portable.

Why to use the big guns that processes and IPC are while threads can do the
job (see Allegro 4.0) ? Under QNX for example, the pthreads API is directly
mapped to kernel calls and thus the thread synchronization functions have a
very low overhead.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx