--
--
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 nod...@googlegroups.com
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
---
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.
I have been writing node.js client code for a couple of years now, and have authored a couple open source libraries, but somehow I missed the memo telling me that I'm supposed to wrap 'synchrounous' callbacks in process.nextTick(). I kind-of understand why that is a best-practice, but what I don't understand is what the drawback is if you don't do it.For example, I write code like this all the time, and have never had a single problem with it:function getSomething(args, cb) {if (!args) { return cb(new Error('args required')); }SomeDatabase.get({id: args.id}, cb);}
It means that things happen in a different order depending on cases — for errors, this is not as likely a problem, but in, say, a caching callback, if the cached values are immediate, and the non-cached values spin the event loop, you have some significantly different behavior depending on which case you're in -- in one case, you have a full stack still, after the event loop spins, you've cleared the stack (and exception handlers).
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
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.
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.
--
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
> Be conservative in what you send, be liberal in what you accept.This is absolutely wrong! You should be conservative in what you accept and conservativein what you send otherwise you get huge troubles, shits and endless "it works here doesn't there" story.Browsers are good example.
>people writing node modules should follow the node patterns and never mix sync and async behavior
There is a certain edge between the case when you should follow common practices event if you don't like themand the case when you shouldn't, because they are so bad that cause a greater damagethan confusing people from time to time.
For the case of nextTick I ignored it, because it's such a PITA.
I am sorry, I had to write more detailed explanation of my above statements.Postel low (Robustness principle)You can have a look at wikipedia article about it http://en.wikipedia.org/wiki/Robustness_principle.It contains explanation about why the robustness principle is harmful and contains a link to the corresponding RFC.About browsers. I am not much aware history of browsers wars, but I am aware aboutHTML parsers and what a shit they are and heard about how much efforts it took to makeall that quirk stuff be a standard. Although browsers had a greater excuse for that than a pure machine protocols.Finally, I personally suffered from "robustness" even within my *private* tool chain :)
process.nextTickDownsides of process.nextTick are1) It is none-standard, not available in other environments and even can't be shimed (with promise of the same performance).
2) It has performance costs. Significant or not depends on your use case.
3) It disables some use cases.
--
--
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 nod...@googlegroups.com
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
---
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.
This all are good arguments, in the theory ... in praxis, I think:1. Most developers do not assume async/sync mixed styles today ...
2. That kind of performance overhead matters in some rare cases, I think ... normally you don't care about 10-15ms ... If the overhead is much higher its about the overall process load ... even if you get your callback faster, some other parts of the application will wait. At the end the whole application will perform at the same speed ... no?
3. This is one of nodejs very bad parts which should be possibly solved on some other level, saving stacks over X loops ... or whatever .... All the longstacktraces modules I have tried have consumed huge amount of memory so its not for production.
On Friday, August 23, 2013 10:21:37 AM UTC-5, Oleg Slobodskoi wrote:This all are good arguments, in the theory ... in praxis, I think:1. Most developers do not assume async/sync mixed styles today ...In practice, coding standard should not be lower because of programmer laziness, right?
2. That kind of performance overhead matters in some rare cases, I think ... normally you don't care about 10-15ms ... If the overhead is much higher its about the overall process load ... even if you get your callback faster, some other parts of the application will wait. At the end the whole application will perform at the same speed ... no?Yes, the overhead matters only in rare cases. But imagine you're writing an API that unfortunately falls into that rare case, what would you do? Do you use nextTick to pay that unnecessary and large overhead, or do you use invoke callback synchronously and add a "CAUTION" in your doc to warn programmers? Both ways are too inelegant IMO. I think the best way to go would be educating programmers to assume all asynchronous calls may be executed synchronously, that way nobody will need to pay the unnecessary overhead (it's a big deal for whose who fall into that rare cases!), and no need to warn your user in the doc.
3. This is one of nodejs very bad parts which should be possibly solved on some other level, saving stacks over X loops ... or whatever .... All the longstacktraces modules I have tried have consumed huge amount of memory so its not for production.I don't think it's nodejs's bad. It's bad programming principle. Throw away your stack information just to guarantee execution order when the user in most cases might not need at all? Seriously?IMO It can be solved very easily. Just don't use nextTick for error handling code. Period.
--
--
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 nod...@googlegroups.com
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
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
Depends on how much pain it causes ... If official nodejs doc warns people then its probably fine ...
I have never seen such cases ... and can't imagine them ... but potentially yes ...
stack trace problem is there independent of the topic ... you are using lots of real async apis which WILL drop your stack trace ....
I have never seen such cases ... and can't imagine them ... but potentially yes ...The cursor.nextObject() of node-mongodb-native that @Eldar has brought up is a pretty good one.
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
However, I'm still unsure of when someone would ever care if I called back immediately in my examples, where I'm just checking for the correct args.
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.
--
Which means you have to wrap pretty much any zalgo-promise, or use some goofy apply mechanism. Assuming you meticulously add all this boilerplate then yes, at this point Juraj is right. It "solves" the problem (with a nextTick or equivalent, of course). But at what cost?
--
You say "this sounds like the opposite of promises solving a problem", which I assume would mean promises creating a problem?
Though if it is, you're doing it wrong. This is not a philosophical opinion. It's empirical fact. Read the section about understanding callback mechanics in this blog post:
http://blog.trevnorris.com/2013/08/callbacks-what-i-said-was.html
Thanks Scott.That's basically what I had gathered from googling around. It seems to me like it's not necessary to wrap in nextTick for most cases then.On Aug 20, 2013, at 10:58 AM, Scott González <scott.g...@gmail.com> wrote:The potential issue is if the person consuming your API expects the callback to always be async:// kick off the async process as early as possibledoAsync( cb );// do some slightly high cost prep work before the callback is invokedprepareStateForCallbackWhileWaiting();Doing the prep work after the async call allows you to reduce the amount of time needed between the start of this tick and the tick when the callback is actually invoked. Interestingly, the reason some people don't like forcing async is for performance gains when the operation can be sync.You're going to get lots of arguments on both sides.On Tue, Aug 20, 2013 at 1:47 PM, Bryan Donovan <brdo...@gmail.com> wrote:
I have been writing node.js client code for a couple of years now, and have authored a couple open source libraries, but somehow I missed the memo telling me that I'm supposed to wrap 'synchrounous' callbacks in process.nextTick(). I kind-of understand why that is a best-practice, but what I don't understand is what the drawback is if you don't do it.For example, I write code like this all the time, and have never had a single problem with it:function getSomething(args, cb) {if (!args) { return cb(new Error('args required')); }SomeDatabase.get({id: args.id}, cb);}What are the potential issues with not wrapping those arg checks in process.nextTick()?Thanks,Bryan
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.