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.
>
> Oleg
>
>
> I think using nextTick() for error handling is a very very bad idea.
>
> Stack trace could be very helpful when error happens. use nextTick
> basically throws that stack trace ability away.
>
> Moreover, the whole nextTick thing is stupid IMO. When I use an
> asynchronous API, I always assume it *may* be optimized for some cases to
> run synchronously. So changing the state of a callback function between it
> is used and it is called is a very very bad idea. In almost every case I
> ran into, it turned out to be a programmer mistake rather than an intended
> behavior. The programmer should *NOT* assume a guaranteed execution order.
> It is a very unnecessary overhead (sometimes also very large) to pay for
> API developers just to guarantee execution order, because execution order
> is irrelevant in most cases.
>
> To sum up,
> 1) Programmer should assume an asynchronous API may callback synchronously
> because of optimization for some fast path.
> 2) Guarantee execution order of a callback is unnecessary in most cases,
> so it's an overhead that should be avoided by default.
> 3) Definitely DO NOT use nextTick for error handling code, because it
> throws away the stack information for nothing.
>
> -Chaoran
>
> On Tuesday, August 20, 2013 12:47:22 PM UTC-5, Bryan Donovan 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')); }
>> if (!args.id) { return cb(new Error('args.id required')); }
>>
>> SomeDatabase.get({id: args.id}, cb);
>> }
>>
>> What are the potential issues with not wrapping those arg checks in
>> process.nextTick()?
>>
>>
>> Thanks,
>>
>> Bryan
>>
>
> --
> --
> 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.
