> > It is critically (and perhaps, counterintuitively) important, when > designing an API, that a callback be called either synchronously, or > asynchronously, but not both. This is the most important thing to > remember. That's why process.nextTick exists. >
I would argue with that. Surely it's a good to have convention and lead's to a great simplification, but: 1) For this convention to work *Every* module should follow it. That's hard to achieve. I would never give to third parties such level of trust. Even if they work correctly today who knows will happen tomorrow. 2) Deferring is not very cheep. It is 1) additional scope, 2) queue management penalty. There are cases when that will lead to a notable performance impact. Actually you rarely know under what conditions your function will be used. >From the above it seems it is safer and simpler to assume that, you should always be prepared to sync returns. And it's not too often when it is a concern actually. On Saturday, April 13, 2013 8:35:57 PM UTC+4, Isaac Schlueter wrote: > > 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 perhaps, counterintuitively) important, when > designing an API, that a callback be called either synchronously, or > asynchronously, but not both. This is the most important thing to > remember. That's why process.nextTick exists. > > This is a great blog post that sums it up better than anything I've > ever read on the subject: > http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ > > In node, there are some non-IO things that do asynchronous callbacks. > setTimeout, setInterval, setImmediate, and process.nextTick all call > their callback asynchronously (after the API function returns). None > of them follow the (err,data) call pattern (except in the trivial > sense that they cannot possibly error, and provide no data, I > suppose). setInterval does not call its call back only once, > obviously. And of the set*() functions return a handle that can be > cancelled, so they might not call their callback at all. > > Node's Zlib library does compression and decompression in a worker > thread. That's not IO, but it is potentially somewhat costly, so > that's why it does it that way. > > It'd be nice to provide asynchronous interface to openssl as well, but > that's a much larger task. (And, it'd be nice to have synchronous > Zlib, but only so many hours in the day, and it's not a high > priority.) > > I would not usually recommend "splitting up" work into chunks and > using process.nextTick or setImmediate. If the work is being done in > the main thread, it's still going to slow things down anyway (albeit > less so if it's broken up), and it'll take much longer to finish. > > The better solution there is to create a child process to do the work > (or use a uv_work request in a C++ binding). And, of course, profile > and simplify your algorithm to make it so that you have to do less > work. If it's not worth doing those things, then it's probably not > really enough work to matter, so you may as well just go ahead and do > it. > > > > On Fri, Apr 12, 2013 at 3:21 AM, Tim Oxley <[email protected] <javascript:>> > wrote: > > > > > > 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 recommending only using function(err, value) pattern for async > > operations? > > > > -- > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "nodejs" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
