avcall, callback, trampoline, vacall, etc

[Rivka Miller]

I am a newbie, but let me hazard a reply from what little I know.

Speaking only for myself, I found the idea of a 'callback' one that was
really easy to describe, but really hard to understand for a long time.
I see some other posters have already pointed you at google on this one,
but I'll give it a shot anyway.

I think the OP wrote in a rather nice way, going back to the original
book on C programming. Even the book by Kernighan and Pike on the Unix
does not touch any of these concepts.

The big thing about callbacks is that everything you know about writing
a program is turned completely on its head.  It sounds like you may have
learned C when I did (or at any rate before these newfangles concepts
came about).  If so, you're used to the idea that your main() is
basically in control, and calls functions you write, more or less one at
a time in an order you specify.  So first you call a function (or some
functions) that read your input; then you call a function that gets some
work done; then you call a function that writes your output.  It's
likely your code isn't that clean in real life; you probably actually
read a little bit of input, do a little bit of work, write a little bit
of output, lather rinse repeat.  Doesn't matter, you're still in control
of when your functions get called.

For callback-based programming, forget all that.  Flush it.

There are areas where a completely different paradigm is used.  A good example
of one of these areas is writing a GUI interface.  The big thing about a
GUI interface is that you don't have control of the order in which input
arrives, and you need to do something about whatever the crazy user
does.  In this world, somebody else writes something called an "event
loop".  The event loop just sits out there waiting for input (maybe a
button click, maybe information that you need to redraw your window,
maybe a timeout, maybe something else), and when the input happens the
event loop code calls a function you wrote to handle that particular
input.  Your function is called a 'callback'.

So that's the idea.  You write a function to handle the user clicking
the 'OK' button.  You write a function to handle a window resize event.
You write a function to...  whatever.  You pass a pointer to your
function to the event loop code (this is called 'registering' your
callback), and just sit back and wait for your code to be called.

As Joe Pfeiffer said that this has to do with a very different
paradigm.
I like Joe's reply as he tries to develop a good reply from basics.
Those
who replied did not seem to add much to it - atleast from my point of
view. And a newbie like the OP would probably be confused on this
subject.
I have a little pedestrian knowledge of the event drive programming.

Perhaps, they would have taken Joe's discussion and developed it
further.

For event-driven programming, you have to start with the concept of a
finite state machine FSM. There are a few variations, Mealy and Moore
machines.
You can also factorize out the states according to alternative,
concurrency and inheritance.

Most often, one sees callbacks when there are javascript code snippets
sent
by the server machine to the client machine browser for calling back
if it needs something.

But the callbacks can also be limited to a single machine with
multiple threads or processes running and able to call each other via
callbacks - I dont know how, but somehow.

Perhaps, someone would take a simple pictorial diagram of an
interesting FSM and translate it into a complete code involving
callbacks - and comparing with the other paradigm if that can also be
done. Or atleast, show how a single transition can be converted to it.
An example of GUI might be worth considering.

R