Re: Fw: Re: [AD] messy allegro 5.0 stuff

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

[about the validity of the argument]
> Yes. :-)

Are you sure you can dismiss a method, based only on the failure of this
single test: "is there at least one case for which the method is the only
one available ?"

> This is a good argument, and I don't know enough to give an accurate
> answer, so I will stick to Linux. At the driver level, it is necessary
> to poll a device to see if there is keyboard input, so asynchronous
> input requires regular polling of this device anyway, which needs to be
> either done via signals or threads.

You mean at the OS driver level, I suppose ?
What if the OS gives you an interrupt-based (DOS) or event-based
(DirectInput) API layer on top of it ? Why not expose it through Allegro ?

> Yes, and also no. As they execute in an interrupt context, you can only
> really set a flag or two and the continue.

Did you take a look at src/misc/pckeys.c:_handle_pckey() ? I wouldn't call
it "setting a flag or two", and it is called for each key event, including
under DOS. Moreover, callbacks don't execute in an interrupt context for
most ports, they rather use threads.

> See above point about needing to poll anyway, and remember that with a
> poll-only API you don't need any threads in the first place.

Ha ! Ha ! Here is the interesting point! ;-)
So, you're willing to completely rewrite the low-level code of each port ?
If so, that's another story: I thought we have been talking about revamping
the API, not rewriting the library.

> Now, if you want an asynchronous API, you need to implement (via threads
> or signals) something which constantly does all this polling, and then
> calls its very limited callbacks.

I don't call 'polling' the method of blocking and waiting for an event. And
again the callbacks can do whatever you want them to do if you are cautious
enough.

> This means that the function-based API
> becomes impossible to implement in the trivial way shown above.

I disagree: it is easy to implement a polling-like API on top of
events/callbacks, you basically just have to use buffers. A contrario, the
opposite is far more complicated.

> I think we both have valid arguments, but I will once again bring
> attention to the huge overhead required to implement such callbacks, and
> the inflexibility of those methods.

Overhead at which level ? At runtime or at implementation-time ? In the
latter case, that's already done.

---
Eric Botcazou
ebotcazou@xxxxxxxxxx