> 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 value and a callback. I think the return value had to be dealt with in the same tick and needing something from the callback. On Sat, Apr 13, 2013 at 11:29 AM, Eldar <[email protected]> wrote: > 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/<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]> 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<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 >> > nodejs+un...@**googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/**group/nodejs?hl=en?hl=en<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 nodejs+un...@**googlegroups.com. >> > For more options, visit >> > https://groups.google.com/**groups/opt_out<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. > > > -- -- 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.
