Also about process.nextTick "standard". You might be surprised, but I very rarely see sync callbacks deferring in modules which our app uses. directly or not.
пятница, 23 августа 2013 г., 0:02:36 UTC+4 пользователь Eldar написал: > > 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 about > HTML parsers and what a shit they are and heard about how much efforts it > took to make > all 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.nextTick* > * > * > Downsides of process.nextTick are > > 1) 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. > > Example for 2 - 3 > > Let's say you have a some streaming app which receives something, > transforms it and sends results further. > > TCP -> PARSER -> TRANSFORM -> SEND > > No surprise that PARSER often receives a chunk which contains many > protocol objects. > So, deferring them with nextTick is a performance overhead. And indeed, > for example > cursor.nextObject() of > node-mongodb-native<https://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/cursor.js#L678> > calls > it's callback synchronously exactly for the same reason. > On other hand SEND also may decide to pack several protocol objects in one > network packet. One possible > and sometimes best way to do that is to consume what is available right > now in the same tick, pack that and send. > This is not possible when objects are deferred. > > About 1) and that it's none-standard I can add that when nextTick > semantics were changed in 0.10.x and temporal max tick depth limitation > were added many module authors were confused. They haven't discovered > process.maxTickDepth setting and patched their code > to use new setImmediate() function instead. Loosing performance of new > process.nextTick and adding a junk to their code. > > Hope, now my claims look more sane and making sens. > > > четверг, 22 августа 2013 г., 22:32:28 UTC+4 пользователь Scott González > написал: >> >> On Thu, Aug 22, 2013 at 2:22 PM, Eldar <[email protected]> wrote: >> >>> > 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 conservative >>> in what you send otherwise you get huge troubles, shits and endless "it >>> works here doesn't there" story. >>> Browsers are good example. >>> >> >> This is so misguided it's not even funny. There's a huge difference >> between being liberal and having defined results for every input and the >> bullshit that went on during the major browser wars. >> >> >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 them >>> and the case when you shouldn't, because they are so bad that cause a >>> greater damage >>> than confusing people from time to time. >>> >> >> You realize that if you want to be conservative as an API developer, you >> need to use nextTick(), right? There's absolutely zero change of danger or >> confusing when forcing async callbacks. All of the danger and confusion >> comes from sometimes-sync callbacks. >> >> >>> For the case of nextTick I ignored it, because it's such a PITA. >>> >> >> Sorry that writing one more line of code is so troublesome for you. >> > -- -- 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.
