Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > avcall, callback, trampoline, vacall, etc

Reply
Thread Tools

avcall, callback, trampoline, vacall, etc

 
 
Rivka Miller
Guest
Posts: n/a
 
      11-06-2012
On Oct 25, 6:18*pm, Joe Pfeiffer <(E-Mail Removed)> wrote:
> (E-Mail Removed) 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: PIL (etc etc etc) on OS X Kevin Walzer Python 4 08-13-2008 08:27 AM
there are too many warnings (you are about to....etc etc forever) after installing Firefox trevor_smithson@yahoo.com Firefox 2 10-13-2005 07:35 PM
user authentication via /etc/passwd|/etc/shadow Marco Herrn Python 7 04-09-2004 12:12 PM
Python Audio (Alpy, Fastaudio, Etc Etc) Daniel Joyce Python 1 09-16-2003 08:39 PM
Is there a standard module library function to access /etc/passwd or /etc/group Robin Cull Python 5 07-31-2003 09:35 PM



Advertisments