There are plenty of examples of people calling things callbacks that
are just a function you pass to another function that gets called
zero or more times. *In Node.js*, callback typically refers to an
asynchronous callback as Jake explained, but not quite 100% of the
time.
It is critically (and
you should always be prepared to sync returns.
+1 I've always done this.
However, one time when I was arguing this someone came back with an usage
example where this was impossible. I don't remember it off the top of my
head but it had something to do with a function both having a return
+1 to C++ module using uv_queue_work() for computation intensive stuff.
If you have some experience with C++ native Node modules are pretty easy to
write, and there are plenty of good examples. It's arguably easier than
writing performance-optimized javascript :-)
On Wednesday, April 10, 2013
On Tuesday, 9 April 2013 23:56:44 UTC-4, Raynos wrote:
@Eldar, that's an iterator function not a callback. A callback is very
specifically a function (err, value) {} that will not be called
synchronously.
I've never heard a callback being very specifically not synchronous? Are
you
the term Callback in node is very bound to function will be called after
async call is done. In general a callback is an instance of the Observer
pattern, which is in fact a variant of the Delegate pattern. and the
function you pass to the forEach is in fact a Delegate or you could call it
Are you recommending only using function(err, value) pattern for async
operations?
Yes. Think of Callback as a type
`CallbackT: (err: Error, value: Value) = void`
It has very specific semantics. it takes two arguments, err is either an
Error or falsey, value is anything. A callback get's
Thanks guys, your suggestions are very helpful to me.
Especially thanks to Geerten for the clarifying summary.
On Wednesday, April 10, 2013 12:02:44 AM UTC+2, Mil Werns wrote:
I have a simple question: When should I use callbacks?
Currently, I'm only using callbacks in I/O cases (file,
Doing cross thread communication is another example of an asynchronous
computation.
What's important here is not that you can run 4 functions in parallel and
utilize 4 cores but that if you run one async bcrypt function it won't
block the main thread.
Doing a CPU bound computation in C++ in a
Keep in mind that callbacks don't necessarily go hand in hand with
asynchroneous behaviour and most certainly don't mean the same (see
Array.forEach vs process.nextTick).
Using callbacks (heavily) is a programming pattern that is used a lot in
node. Just for this reason, a lot of npm modules
No, you get it all wrong.
Callbacks you use for `for-loops` (array.forEach() I guess) are not async
at all.
The forEach() method is actually nothing but:
// simplified
Array.prototype.forEach = function (cb) {
for (var i = 0; i this.length; i++) {
cb(this[i])
}
}
So it just performs
As javascript is single threaded you usually don't need callback unless
it's IO related. However, there are exceptions:
(i) Heavy calculations might want to utilize process.nextTick() or
timeout, to avoid blocking. You would have to use a callback to return
the final results
(ii)
As javascript is single threaded you usually don't need callback unless
it's IO related. However, there are exceptions:
(i) Heavy calculations might want to utilize process.nextTick() or
timeout, to avoid blocking. You would have to use a callback to return
the final results
(ii)
@Eldar, that's an iterator function not a callback. A callback is very
specifically a function (err, value) {} that will not be called
synchronously.
@Sigurgeir Webworkers do IO. The message passing is cross thread
communication which is IO.
My stance on using process.nextTick to time slice
Don't forget that there is thread pool in node, and some native modules
provide async api for CPU-bound functions and use pool internally.
For example, if you try to benchmart bcrypt[1] using synchronous api you'll
get 100% CPU (one core busy), and if you run 4 bcrypt functions in parallel
14 matches
Mail list logo
