Very simply, a callback needn’t be asynchronous.
http://docs.apigee.com/api-baas/asynchronous-vs-synchronous-calls
- Synchronous:
If an API call is synchronous, it means that code execution will
block (or wait) for the API call to return before continuing. This
means that until a response is returned by the API, your application
will not execute any further, which could be perceived by the user as
latency or performance lag in your app. Making an API call
synchronously can be beneficial, however, if there if code in your app
that will only execute properly once the API response is received.
- Asynchronous:
Asynchronous calls do not block (or wait) for the API call to return
from the server. Execution continues on in your program, and when the
call returns from the server, a “callback” function is executed.
In Java, C and C#, “callbacks” are usually synchronous (with respect to a “main event loop”).
In Javascript, on the other hand, callbacks are usually asynchronous – you pass a function that will be invoked … but other events will continue to be processed until the callback is invoked.
If you don’t care what Javascript events occur in which order – great. Otherwise, one very powerful mechanism for managing asynchronous behavior in Javascript is to use “promises”:
http://www.html5rocks.com/en/tutorials/es6/promises/
PS:
To answer your additional questions:
-
Yes, a callback may be a lambda – but it’s not a requirement.
In Javascript, just about every callback will be an “anonymous function” (basically a “lambda expression”).
-
Yes, callbacks may be invoked from a different thread – but it’s certainly not a requirement.
-
Callbacks may also (and often do) spawn a thread (thus making themselves “asynchronous”).
====================================================================
Q: @paulsm4 can you please elaborate with an example how the callback
and asynchronous call works in the execution flow? That will be
greatly helpful
- First we need to agree on a definition for “callback”. Here’s a good one:
https://en.wikipedia.org/wiki/Callback_%28computer_programming%29
In computer programming, a callback is a piece of executable code that
is passed as an argument to other code, which is expected to call back
(execute) the argument at some convenient time. The invocation may be
immediate as in a synchronous callback, or it might happen at a later
time as in an asynchronous callback.
-
We must also define “synchronous” and “asynchronous”. Basically – if a callback does all it’s work before returning to the caller, it’s “synchronous”. If it can return to the caller immediately after it’s invoked – and the caller and the callback can work in parallel – then it’s “asynchronous”.
-
The problem with synchronous callbacks is they can appear to “hang”. The problem with asynchronous callbacks is you can lose control of “ordering” – you can’t necessarily guarantee that “A” will occur before “B”.
-
Common examples of callbacks include:
a) a button press handler (each different “button” will have a different “response”). These are usually invoked “asynchronousy” (by the GUI’s main event loop).
b) a sort “compare” function (so a common “sort()” function can handle different data types). These are usually invoked “synchronously” (called directly by your program).
-
A CONCRETE EXAMPLE:
a) I have a “C” language program with a “print()” function.
b) “print()” is designed to use one of three callbacks: “PrintHP()”, “PrintCanon()” and “PrintPDF()”.
c) “PrintPDF()” calls a library to render my data in PDF. It’s synchronous – the program doesn’t return back from “print()” until the .pdf rendering is complete. It usually goes pretty quickly, so there’s no problem.
d) I’ve coded “PrintHP()” and “PrintCanon()” to spawn threads to do the I/O to the physical printer. “Print()” exits as soon as the thread is created; the actual “printing” goes on in parallel with program execution. These two callbacks are “asynchronous”.
Q: Make sense? Does that help?