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

[Laurence Withers <lwithers@xxxxxxxxxx>]

In reply to Eric Botcazou <ebotcazou@xxxxxxxxxx>:
>Laurence wrote:
>> Can somebody please give me an example of a nice, consistent program which
>> uses callbacks and where another method just wouldn't do?
>
>Firstly, is that really a valid argument ?

Yes. :-)

> Can it not be applied to the
>notion of recursive functions as well for example: why to use recursive
>functions since there is always a equivalent non recursive method to do the
>job ?

Ignoring that usual silly example of calculating factorials, there are
some extremely non-trivial examples of where recursive functions are
good. But there are two ways to implement recursive solutions to
problems:

1/. Use recursive functions
    Great on the PC, because you can recursively call a function 
    millions of times without running out of stack space. Simpler to
    code than implementing your own stack.

    Not great on, say, the PIC, where you have only 8 stack frames (1 of
    which is h/w controlled and reserved for interrupts).

2/. Implement your own stack
    More efficient (less function calls), but takes longer to code. 
    Overcomes stack limitations.

So, recursive functions may be the easiest to code, but it is better to
implement your own stack and not call recursively. Opting for the
easiest path isn't always opting for the best path.

>You obviously don't want to poll between each byte.

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.

>Callbacks are useful (not necessary, like recursive functions are not
>necessary) when you want to do pure asynchronous event processing.

Yes, and also no. As they execute in an interrupt context, you can only
really set a flag or two and the continue. You then need to poll the
flag anyway, so why not just poll the device? OK, it is less efficient
to call select() on your device, but it is more direct: there are no
threads/timers/function callbacks to execute/whatever causing overhead.

> Of course
>you could set up your own thread, but why would you want to increase
>again the system overhead ?

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.

Another advantage of having your own thread is that this thread can be
as convoluted as you want; there are no limitations.

>Allegro is a low-level library (Allegro Low-Level Game Routines), so why to
>impose a model (polling) over another one (events/callbacks) ?

Because polling is how nearly all (ie. except DOS) OSs work. I refer to
Shawn's comments that Allegro is successful because its concepts map
closely to what the hardware does. Consider that each function in the
proposed keyboard API can be implemented as:

return_type al_keyboard_function(...)
{
    keyboard_driver->poll();
    /* read status of keyboard driver and do something */
}

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. This means that the function-based API
becomes impossible to implement in the trivial way shown above.

>To sum up a little, and to paraphrase a former British female Prime Minister
>about a completely different topic: "I want my callbacks back !" ;-)

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.

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature