avcall, callback, trampoline, vacall, etc

Discussion in 'C++' started by gnuist007@hotmail.com, Oct 25, 2012.

  1. Guest

    Dear Programming Gurus,

    These concepts are rather well talked about .. over the internet and
    usenet, however, I cant find any clear explanation.

    avcall, callback, trampoline, vacall, etc

    I looked in a book of C programming, ie k&r and also the rationale for
    C, an old copy and could not find any explanation.

    I know that javascript books talk a lot about callbacks and there is
    the style of programming involving writing callbacks and registering
    them. Unfortunately, in the age when I took my C class, there was no
    discussion along these lines.

    Can anyone give clear definition, example, benefits, variations,
    origin or citation to a paper where it originated and explained first,
    as well as some modern text that does the better than most job of
    illustrating it and its applications.
     
    , Oct 25, 2012
    #1
    1. Advertising

  2. James Kuyper Guest

    On 10/25/2012 03:24 PM, wrote:
    > Dear Programming Gurus,
    >
    > These concepts are rather well talked about .. over the internet and
    > usenet, however, I cant find any clear explanation.
    >
    > avcall, callback, trampoline, vacall, etc
    >
    > I looked in a book of C programming, ie k&r and also the rationale for
    > C, an old copy and could not find any explanation.
    >
    > I know that javascript books talk a lot about callbacks and there is
    > the style of programming involving writing callbacks and registering
    > them. Unfortunately, in the age when I took my C class, there was no
    > discussion along these lines.
    >
    > Can anyone give clear definition, example, benefits, variations,
    > origin or citation to a paper where it originated and explained first,
    > as well as some modern text that does the better than most job of
    > illustrating it and its applications.


    When a C function takes as an argument a pointer to another function,
    the function pointed at is often referred to as a callback function.
    Examples from the C standard library include qsort() and bsearch(),
    where the callback function is called in order to determine the relative
    order of the records processed by those functions.

    I know nothing about vacall or avcall. I've heard of trampolines in the
    context of computer programming, but know little about them.

    For all questions like this, I would recommend starting with wikipedia -
    it generally does a good job of explaining computer-oriented technical
    terms like these; if you don't find it there, try google.
     
    James Kuyper, Oct 25, 2012
    #2
    1. Advertising

  3. Cortez Guest

    On Oct 25, 8:24 pm, wrote:
    > Dear Programming Gurus,
    >
    > These concepts are rather well talked about .. over the internet and
    > usenet, however, I cant find any clear explanation.
    >
    > avcall, callback, trampoline, vacall, etc
    >
    > I looked in a book of C programming, ie k&r and also the rationale for
    > C, an old copy and could not find any explanation.
    >
    > I know that javascript books talk a lot about callbacks and there is
    > the style of programming involving writing callbacks and registering
    > them. Unfortunately, in the age when I took my C class, there was no
    > discussion along these lines.
    >
    > Can anyone give clear definition, example, benefits, variations,
    > origin or citation to a paper where it originated and explained first,
    > as well as some modern text that does the better than most job of
    > illustrating it and its applications.


    There's a trampoline function in Clojure, but I really don't know much
    about it, or whether it's even the same thing as you're talking about.
    This article seems to suggest it is:

    http://pramode.net/clojure/2010/05/08/clojure-trampoline/
     
    Cortez, Oct 25, 2012
    #3
  4. On Thu, 25 Oct 2012 16:04:10 -0400, James Kuyper
    <> wrote:

    >On 10/25/2012 03:24 PM, wrote:
    >> Dear Programming Gurus,
    >>
    >> These concepts are rather well talked about .. over the internet and
    >> usenet, however, I cant find any clear explanation.
    >>
    >> avcall, callback, trampoline, vacall, etc

    ^^^1^^ ^^^^2^^^ ^^^^^3^^^^ ^^^4^^

    GIYF!

    1) Google for "avcall". For me, it was the first link.

    2) Google for "callback". For me, it was the first link.

    3) Google for "programming trampoline". For me, it was the first
    link.

    4) This one is a bit tougher. Noting that avcall got me a .h, I
    Googled for "vacall.h". For me, the fourth link is for the vacall(3)
    Linux man page.

    [snip]

    >> Can anyone give clear definition, example, benefits, variations,
    >> origin or citation to a paper where it originated and explained first,
    >> as well as some modern text that does the better than most job of
    >> illustrating it and its applications.


    Did you even bother looking first?

    I had only heard of two of them and was able to find all four
    fairly easily.

    >When a C function takes as an argument a pointer to another function,
    >the function pointed at is often referred to as a callback function.
    >Examples from the C standard library include qsort() and bsearch(),
    >where the callback function is called in order to determine the relative
    >order of the records processed by those functions.
    >
    >I know nothing about vacall or avcall. I've heard of trampolines in the
    >context of computer programming, but know little about them.
    >
    >For all questions like this, I would recommend starting with wikipedia -
    >it generally does a good job of explaining computer-oriented technical
    >terms like these; if you don't find it there, try google.


    Agreed about Wikipedia's reliability in this area, but I prefer
    to use Google first. One can find out about more groups that way and
    even lanaguage standards. If Google returns a Wikipedia link, I will
    usually have a look.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Oct 25, 2012
    #4
  5. Joe Pfeiffer Guest

    writes:

    > Dear Programming Gurus,
    >
    > These concepts are rather well talked about .. over the internet and
    > usenet, however, I cant find any clear explanation.
    >
    > avcall, callback, trampoline, vacall, etc


    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.

    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.

    Another application of callbacks is in FUSE (Filesystem in User SpacE)
    filesystems. I will somewhat immodestly suggest that a tutorial on FUSE
    that you can find at http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/ may
    help you.
     
    Joe Pfeiffer, Oct 26, 2012
    #5
  6. Les Cargill Guest

    wrote:
    > Dear Programming Gurus,
    >
    > These concepts are rather well talked about .. over the internet and
    > usenet, however, I cant find any clear explanation.
    >
    > avcall, callback, trampoline, vacall, etc
    >
    > I looked in a book of C programming, ie k&r and also the rationale for
    > C, an old copy and could not find any explanation.
    >
    > I know that javascript books talk a lot about callbacks and there is
    > the style of programming involving writing callbacks and registering
    > them. Unfortunately, in the age when I took my C class, there was no
    > discussion along these lines.
    >
    > Can anyone give clear definition, example, benefits, variations,
    > origin or citation to a paper where it originated and explained first,
    > as well as some modern text that does the better than most job of
    > illustrating it and its applications.
    >


    "Callbacks" are a method of storing pointers to functions
    and exploiting them.

    I'm answering from comp.lang.c so one thing I would start with is to
    learn the concept of an ioctl(). It's one of the oldest ways to
    do this sort of thing. Just google for "device driver programming in
    linux" and follow some of the simpler examples. ioctl() is a pattern
    that occurs quite frequently, in and out of kernel/driver
    development.

    After that, just do plain old callbacks in 'C' - declare...

    //a typedef

    typedef void (*cbtype)(char *);

    // an array of them

    cbtype cbtab[3];

    // an initializer

    void set_cb(cbtype a,int idx)
    {
    ....
    }

    // and reference the callbacks

    void thing(char *s)
    {
    ....
    }

    ....

    set_cb(thing,2);
    cbtab[2]("Calling Elvis");

    --
    Les Cargill
     
    Les Cargill, Oct 26, 2012
    #6
  7. Guest

    On Oct 25, 7:18 pm, Joe Pfeiffer <> wrote:
    > writes:
    > > Dear Programming Gurus,

    >
    > > These concepts are rather well talked about .. over the internet and
    > > usenet, however, I cant find any clear explanation.

    >
    > > avcall, callback, trampoline, vacall, etc

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


    I think, the above paras were what I was wanting as a reply although
    all replies were useful. What I want to consolidate is really some
    good and illustrative toy examples. Can you cook any or have a link to
    some that you have whetted are good?

    > Another application of callbacks is in FUSE (Filesystem in User SpacE)
    > filesystems.  I will somewhat immodestly suggest that a tutorial on FUSE
    > that you can find athttp://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/may
    > help you.


    I come to this after you give some examples of the first idea.
     
    , Oct 26, 2012
    #7
  8. Guest

    On Oct 26, 5:27 am, Les Cargill <> wrote:
    > wrote:
    > > Dear Programming Gurus,

    >
    > > These concepts are rather well talked about .. over the internet and
    > > usenet, however, I cant find any clear explanation.

    >
    > > avcall, callback, trampoline, vacall, etc

    >
    > > I looked in a book of C programming, ie k&r and also the rationale for
    > > C, an old copy and could not find any explanation.

    >
    > > I know that javascript books talk a lot about callbacks and there is
    > > the style of programming involving writing callbacks and registering
    > > them. Unfortunately, in the age when I took my C class, there was no
    > > discussion along these lines.

    >
    > > Can anyone give clear definition, example, benefits, variations,
    > > origin or citation to a paper where it originated and explained first,
    > > as well as some modern text that does the better than most job of
    > > illustrating it and its applications.

    >
    > "Callbacks" are a method of storing pointers to functions
    > and exploiting them.
    >
    > I'm answering from comp.lang.c so one thing I would start with is to
    > learn the concept of an ioctl(). It's one of the oldest ways to
    > do this sort of thing. Just google for "device driver programming in
    > linux" and follow some of the simpler examples. ioctl() is a pattern
    > that occurs quite frequently, in and out of kernel/driver
    > development.


    For starters, I always start with google and wikipedia. I could not
    find any examples.

    I am asking here so that you guys can give me whetted and good
    examples for a newbie.

    there are books on defice driver programming. I need the part that you
    can make into a small paper. Give me a reference to read that you have
    read yourself and appreciate, maybe a citeseer link to paper etc.

    >
    > After that, just do plain old callbacks in 'C' - declare...
    >
    > //a typedef
    >
    > typedef void (*cbtype)(char *);
    >
    > // an array of them
    >
    > cbtype cbtab[3];
    >
    > // an initializer
    >
    > void set_cb(cbtype a,int idx)
    > {
    > ...
    >
    > }
    >
    > // and reference the callbacks
    >
    > void thing(char *s)
    > {
    > ...
    >
    > }
    >
    > ...
    >
    >    set_cb(thing,2);
    >    cbtab[2]("Calling Elvis");
    >
    > --
    > Les Cargill
     
    , Oct 26, 2012
    #8
  9. Les Cargill Guest

    wrote:
    > On Oct 26, 5:27 am, Les Cargill <> wrote:
    >> wrote:
    >>> Dear Programming Gurus,

    >>
    >>> These concepts are rather well talked about .. over the internet and
    >>> usenet, however, I cant find any clear explanation.

    >>
    >>> avcall, callback, trampoline, vacall, etc

    >>
    >>> I looked in a book of C programming, ie k&r and also the rationale for
    >>> C, an old copy and could not find any explanation.

    >>
    >>> I know that javascript books talk a lot about callbacks and there is
    >>> the style of programming involving writing callbacks and registering
    >>> them. Unfortunately, in the age when I took my C class, there was no
    >>> discussion along these lines.

    >>
    >>> Can anyone give clear definition, example, benefits, variations,
    >>> origin or citation to a paper where it originated and explained first,
    >>> as well as some modern text that does the better than most job of
    >>> illustrating it and its applications.

    >>
    >> "Callbacks" are a method of storing pointers to functions
    >> and exploiting them.
    >>
    >> I'm answering from comp.lang.c so one thing I would start with is to
    >> learn the concept of an ioctl(). It's one of the oldest ways to
    >> do this sort of thing. Just google for "device driver programming in
    >> linux" and follow some of the simpler examples. ioctl() is a pattern
    >> that occurs quite frequently, in and out of kernel/driver
    >> development.

    >
    > For starters, I always start with google and wikipedia. I could not
    > find any examples.
    >
    > I am asking here so that you guys can give me whetted and good
    > examples for a newbie.
    >


    Yes, you made that clear :). There is a superset of the callback()
    concept embedded in developing device drivers. That's where Google
    is helpful.

    They offer trivial "device drivers" so you can learn the toolset.
    The point is that device drivers are one of the most venerable
    ways to do callbacks.

    > there are books on defice driver programming. I need the part that you
    > can make into a small paper. Give me a reference to read that you have
    > read yourself and appreciate, maybe a citeseer link to paper etc.
    >


    So fill in the code I posted directly. It's a simple enough
    example template. Try it, and ask questions if you get stuck.

    It's not necessarily *worth* a paper; it's a couple dozen lines
    of 'C'...

    >>
    >> After that, just do plain old callbacks in 'C' - declare...
    >>
    >> //a typedef
    >>
    >> typedef void (*cbtype)(char *);
    >>
    >> // an array of them
    >>
    >> cbtype cbtab[3];
    >>
    >> // an initializer
    >>
    >> void set_cb(cbtype a,int idx)
    >> {
    >> ...
    >>
    >> }
    >>
    >> // and reference the callbacks
    >>
    >> void thing(char *s)
    >> {
    >> ...
    >>
    >> }
    >>
    >> ...
    >>
    >> set_cb(thing,2);
    >> cbtab[2]("Calling Elvis");
    >>
    >> --
    >> Les Cargill

    >


    --
    Les Cargill
     
    Les Cargill, Oct 26, 2012
    #9
  10. James Kuyper Guest

    On 10/26/2012 01:16 PM, wrote:
    ....
    > For starters, I always start with google and wikipedia. I could not
    > find any examples.
    >
    > I am asking here so that you guys can give me whetted and good
    > examples for a newbie.


    I pointed out that qsort() and bsearch() are good simple examples of how
    callbacks are used, and I recommended searching
    Wikipedia.<http://en.wikipedia.org/wiki/Callback_%28computer_programming%29>
    has two completely filled out toy examples of code using callback
    functions. Joe Pfeiffer pointed you at a tutorial for FUSE, which is a
    more complicated system making use of callbacks. Les Cargill gave you a
    basic template for implementing callbacks in C.

    Callback are a relatively simple concept. Everything that makes a
    callback be a callback is present in both Wikipedia's examples and in
    Les Cargill's template. If there's something more that you need, that
    wasn't provided by those examples, then you're looking for something
    more than just a callback. Perhaps you could explain in more detail what
    you're looking for that was missing from these examples?
     
    James Kuyper, Oct 26, 2012
    #10
  11. Jorgen Grahn Guest

    [Trimmed the newsgroups a bit ... probably not enough]

    On Fri, 2012-10-26, Joe Pfeiffer wrote:
    > writes:
    >
    >> Dear Programming Gurus,
    >>
    >> These concepts are rather well talked about .. over the internet and
    >> usenet, however, I cant find any clear explanation.
    >>
    >> avcall, callback, trampoline, vacall, etc

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


    [snip]

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


    I think you're exaggerating a bit here. But sure, callbacks are a bit
    funny, and worth thinking about before trying to use them.

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


    It seems to be very popular to design GUI frameworks that way, but
    there is nothing that /forces/ them to do it. The fact that a GUI
    application is (at leasr partly) driven by user input doesn't mean you
    have to resort to callbacks.

    Of course if a certain GUI framework forces you to use callbacks, you
    have to do it.

    [snip]

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 27, 2012
    #11
  12. Joe Pfeiffer Guest

    Jorgen Grahn <> writes:

    > [Trimmed the newsgroups a bit ... probably not enough]
    >
    > On Fri, 2012-10-26, Joe Pfeiffer wrote:
    >> writes:
    >>
    >>> Dear Programming Gurus,
    >>>
    >>> These concepts are rather well talked about .. over the internet and
    >>> usenet, however, I cant find any clear explanation.
    >>>
    >>> avcall, callback, trampoline, vacall, etc

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

    >
    > [snip]
    >
    >> For callback-based programming, forget all that. Flush it.

    >
    > I think you're exaggerating a bit here. But sure, callbacks are a bit
    > funny, and worth thinking about before trying to use them.


    I don't think I'm exaggerating at all. This is one of those areas where
    your previous intuitions about how a program fits together will do more
    harm than good, and a necessary first step is to forget your previous
    intuitions.

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

    >
    > It seems to be very popular to design GUI frameworks that way, but
    > there is nothing that /forces/ them to do it. The fact that a GUI
    > application is (at leasr partly) driven by user input doesn't mean you
    > have to resort to callbacks.
    >
    > Of course if a certain GUI framework forces you to use callbacks, you
    > have to do it.


    And since the context of my post was somebody asking for help
    understanding callbacks, that is the class of GUI program I described.
     
    Joe Pfeiffer, Oct 28, 2012
    #12
  13. Guest

    Joe Pfeiffer <> wrote:
    > Jorgen Grahn <> writes:
    >
    >> [Trimmed the newsgroups a bit ... probably not enough]
    >>
    >> On Fri, 2012-10-26, Joe Pfeiffer wrote:
    >>> writes:
    >>>
    >>>> Dear Programming Gurus,
    >>>>
    >>>> These concepts are rather well talked about .. over the internet and
    >>>> usenet, however, I cant find any clear explanation.
    >>>>
    >>>> avcall, callback, trampoline, vacall, etc
    >>>
    >>> 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.

    >>
    >> [snip]
    >>
    >>> For callback-based programming, forget all that. Flush it.

    >>
    >> I think you're exaggerating a bit here. But sure, callbacks are a bit
    >> funny, and worth thinking about before trying to use them.

    >
    > I don't think I'm exaggerating at all. This is one of those areas where
    > your previous intuitions about how a program fits together will do more
    > harm than good, and a necessary first step is to forget your previous
    > intuitions.


    I don't think it helps if you think of callback as something magic and entirely different.

    Probably it's worth taking a look on the 'other side' of callbacks, namely the point where they are called.

    An example:

    Suppose you have created your own little file format. You use it in your console application.

    Of course you have written a parser for it:

    Document* ParseFile(const char* filename)
    {
    // do some parsing
    if (someErrorHappened)
    {
    // only minor error, continue parsing
    printf("Error %x: %s", errorCode, errorMessage);
    }
    // do some more parsing
    if (someErrorHappened)
    {
    // only minor error, continue parsing
    printf("Error %x: %s", errorCode, errorMessage);
    }
    // finish parsing
    return document;
    }

    Now you write a different application, where printing the error message on the console is not appropriate, instead you want to store all errors in a database.

    Of course you don't want to write a new parser for that, but modify the existing one such that it works for both programs.

    To achieve that goal you define an error callback, so every application can do its own error handling:

    typedef void (errorCallback)(int, const char*);

    Document* ParseFile(const char* filename, errorCallback* errorHandler)
    {
    // do some parsing
    if (someErrorHappened)
    {
    // instead of calling printf directly, use the generic error handler
    errorHandler(errorCode, errorMessage);
    }
    // do some more parsing
    if (someErrorHappened)
    {
    // only minor error, continue parsing
    errorHandler(errorCode, errorMessage);
    }
    // finish parsing
    return document;
    }

    In your first console application you define the error handler like this:

    void consoleErrorHandler(int errorCode, const char* message)
    {
    printf("Error %x: %s", errorCode, errorMessage);
    }

    and you call the parsing function:

    Document* document = ParseFile("testfile.txt", &consoleErrorHandler);

    In your second application you define a different error callback:

    void writeErrorToDatabase(int errorCode, const char* message)
    {
    // write error to database
    }

    Document* document = ParseFile("testfile.txt", &writeErrorToDatabase);

    You see, no magic, everything is under your control.

    Tobi
     
    , Oct 28, 2012
    #13
  14. Joe Pfeiffer <> writes:

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


    Yes, but in general, there is still this direct and simple flow of
    control: a function calls another function, and so on.

    A callback is just a function that is given to some module, to be called
    when the module needs to call it. This is a way to parameterize or
    customize that module.

    (defun my-callback (data)
    (format t "Received ~A~%" data))

    (defun receive-loop (data-callback)
    (loop
    :for line = (progn (format *query-io* "> ")
    (finish-output *query-io*)
    (read-line *query-io* nil nil))
    :while (and line (plusp (length line)))
    :do (funcall data-callback line)))

    cl-user> (receive-loop 'my-callback)
    > Hello

    Received Hello
    > World

    Received World
    >

    nil
    cl-user>

    And then you can use the receive-loop module with a different callback,
    making it do something else:


    cl-user> (let ((c 0))
    (receive-loop (lambda (data) (incf c (parse-integer data))))
    c)
    > 42
    > 33
    > 101
    >

    176
    cl-user>


    Now, there's another situation where you really don't know WHEN the
    callback is called, it's when the module calling it uses threads, and
    calls your callback function at "random" times, possibly in another
    thread, or perhaps while handling a unix signal. In this situation,
    there are a lot of technicalities to fulfill for calbacks.


    But the in usual case, there's no complexity involved.

    --
    __Pascal Bourguignon__
    http://www.informatimago.com
     
    Pascal J. Bourguignon, Oct 28, 2012
    #14
  15. Jorgen Grahn Guest

    On Sun, 2012-10-28, Joe Pfeiffer wrote:
    > Jorgen Grahn <> writes:
    >
    >> [Trimmed the newsgroups a bit ... probably not enough]
    >>
    >> On Fri, 2012-10-26, Joe Pfeiffer wrote:
    >>> writes:
    >>>
    >>>> Dear Programming Gurus,
    >>>>
    >>>> These concepts are rather well talked about .. over the internet and
    >>>> usenet, however, I cant find any clear explanation.
    >>>>
    >>>> avcall, callback, trampoline, vacall, etc
    >>>
    >>> 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.

    >>
    >> [snip]
    >>
    >>> For callback-based programming, forget all that. Flush it.

    >>
    >> I think you're exaggerating a bit here. But sure, callbacks are a bit
    >> funny, and worth thinking about before trying to use them.

    >
    > I don't think I'm exaggerating at all. This is one of those areas where
    > your previous intuitions about how a program fits together will do more
    > harm than good, and a necessary first step is to forget your previous
    > intuitions.


    Then we disagree slightly. And that's fine -- the OP has seen two
    opinions, and can make up his own mind.

    Perhaps I'm overly sensitive to "forget everything you think you
    know!" messages.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 29, 2012
    #15
  16. Rivka Miller Guest

    On Oct 25, 6:18 pm, Joe Pfeiffer <> wrote:
    > writes:
    > > Dear Programming Gurus,

    >
    > > These concepts are rather well talked about .. over the internet and
    > > usenet, however, I cant find any clear explanation.

    >
    > > avcall, callback, trampoline, vacall, etc


    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

    > Another application of callbacks is in FUSE (Filesystem in User SpacE)
    > filesystems.  I will somewhat immodestly suggest that a tutorial on FUSE
    > that you can find athttp://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/may
    > help you.
     
    Rivka Miller, Nov 6, 2012
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Covington Bradshaw

    Trampoline code

    Covington Bradshaw, Aug 29, 2004, in forum: Java
    Replies:
    3
    Views:
    504
    Bryan E. Boone
    Aug 30, 2004
  2. Covington Bradshaw

    Trampoline code again

    Covington Bradshaw, Sep 2, 2004, in forum: Java
    Replies:
    5
    Views:
    1,539
    Chris Uppal
    Sep 5, 2004
  3. Hans Kiehn
    Replies:
    0
    Views:
    586
    Hans Kiehn
    Nov 24, 2004
  4. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    438
    Fredrik Lundh
    Aug 13, 2008
  5. Replies:
    20
    Views:
    688
    Rivka Miller
    Nov 6, 2012
Loading...

Share This Page