On Thu, Oct 11, 2012 at 2:19 PM, Tim Oxley <[email protected]> wrote: >> I think what the OP means, is that library authors should wrap >> *synchronous* callback calls in process.nextTick > > > …yep, I mean wrap synchronous callbacks if there's any possibility the > function might execute asynchronously… though Tim Caswell suggests above > that this may not be best practice, and I am eagerly awaiting further > elaboration.
I'm merely saying that there are situations where the performance matters more than preventing users of your code from shooting themselves in the foot and a blanket rule to *always* be consistent is a bit much. This is less of a problem now that nextTick is a lot faster than it used to be. On the whole, I agree that being consistent does make things easier for people using your library. I'm just unsure if it's worth the cost. That is all. I'd rather see client patterns that are immune to callbacks being called before the function returns sometimes. > > -Tim > > > On Friday, 12 October 2012 03:40:42 UTC+10, Adam Crabtree wrote: >> >> I think what the OP means, is that library authors should wrap >> *synchronous* callback calls in process.nextTick, which is a best practice. >> >> If you're saying (possibly) that it's not, then I disagree. Library code >> should be predictable, not synchronous in some cases and asynchronous in >> others. process.nextTick is not slower, it adds only the minimal >> deprioritization necessary to execute your code asynchronously (i.e. >> consistently). This does not undermine any cache performance as nextTick >> executes on the order of <1ms, significantly faster than any I/O. >> >> Cheers, >> Adam Crabtree >> >> On Thu, Oct 11, 2012 at 7:51 AM, Axel Kittenberger <[email protected]> >> wrote: >>> >>> > Inconsistent sync/async >>> > When functions are sometimes sync and sometimes async lead to hard to >>> > use >>> > apis, subtle bugs and more error handling wrapper code. Always wrap >>> > callbacks in process.nextTick if they're not behind an async operation. >>> > Simple. >>> >>> As others have written, if you have to have to do this,then your async >>> handling is cranked up. Caches aren't there for nothing. If the callee >>> depends on a particular order that it is in error not you, and I'd >>> rather see errors fixed than leaving them in and not raising'em. I >>> won't say, use one of the 1000ooo.... (a)sync libraries, but if the >>> callee would use one of them (like my favorite streamline) the >>> "problem" won't be one, and that one for example will get good >>> performance using trampolining technology. This is only sanely >>> available to you if you are the application developer, if you develop >>> a library, just take care. >>> >>> -- >>> 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 >> >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 > > -- > 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 -- 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
