Wow. Jason Brumwell is amazing :) > For "configurable error handler call", are you referring to timeouts only? If so the description of `cb` is accurate, otherwise not exactly.
Yes, probably I should change the definition. What I meant is "does it allow to call the same callback on timeout with args different from (new TimeoutError)?". Especially this case is useful when using some 3rd party libs' callbacks that always expect to be called as (err, result), as in the case with async.parallel. Am I mistaken regarding cb in this case? > Not sure what is being compared here: "can forcibly freecallbackbefore ..." In the case of cb there is a function returned from the cb() call. Then you pass this function as a callback to somewhere where it's wired with an additional ref and even if it will be timed out, it will still persist in the memory. In the case of cb, the only thing remain after a callback is timed out: it's the id that was assigned to this callback. And more than that, this id will remain not in the process where the callback was assigned but rather on a different server. On Sat, Nov 10, 2012 at 7:15 AM, jmar777 <[email protected]> wrote: > Nice work on the comparisons. A couple questions: > > - For "configurable error handler call", are you referring to timeouts > only? If so the description of `cb` is accurate, otherwise not exactly. > - Not sure what is being compared here: "can forcibly freecallbackbefore > ..." > > Also, it appears that your table has inspired some `cb` pull requests to > reach feature parity with node-candle: https://github.com/jmar777/cb/pulls > > I love Open Source :) > > > On Thursday, November 8, 2012 1:41:31 AM UTC-5, Alexey Kupershtokh wrote: >> >> jmar777, >> https://github.com/**AlexeyKupershtokh/node-candle/**wiki/Todo<https://github.com/AlexeyKupershtokh/node-candle/wiki/Todo> >> check out the table please >> >> суббота, 3 ноября 2012 г., 4:46:11 UTC+7 пользователь jmar777 написал: >>> >>> Very interesting - I wasn't aware of the set/clearTimeout optimizations. >>> And yes, you're correct about the scope of my module - it's just a >>> lightweight utility for handling timeouts and enforcing certain callback >>> execution semantics. >>> >>> On Friday, November 2, 2012 10:15:03 AM UTC-4, Alexey Kupershtokh wrote: >>>> >>>> Thank you :) It's very pleasant to meet a person that feels the same >>>> problem very well! >>>> Yes, one of the key points is exactly handling the map of callbacks. >>>> Do I understand correctly that your cb module stands in one row with >>>> addTimeout and future and doesn't provide freeing callbacks on it's own? >>>> >>>> Since you've written a similar module too, you would likely want to >>>> know that one of high speed factors of the module was using optimized >>>> versions of setTimeout (1.05..1.5 times) and clearTimeout (20-30 times >>>> faster :)). I've created a pull request ( https://github.com/joyent/** >>>> node/pull/4193 <https://github.com/joyent/node/pull/4193> ) for >>>> node.js. More details and benchmarks are here - >>>> https://github.com/joyent/**node/issues/4225#issuecomment-**9971557<https://github.com/joyent/node/issues/4225#issuecomment-9971557> >>>> >>>> пятница, 2 ноября 2012 г., 20:03:14 UTC+7 пользователь jmar777 написал: >>>>> >>>>> Looks like an interesting idea. We had to build some similar >>>>> functionality for wrapping some fairly indeterminate behavior to a >>>>> request/response model. Part of our solution there was a utility that at >>>>> least offered some of the timeout handling: https://github.com/** >>>>> jmar777/cb <https://github.com/jmar777/cb> >>>>> >>>>> Using the above, we then just had a map that kept track of callbacks >>>>> keyed by an id (which looks like that's part of the problem candle >>>>> addresses). Nice work! >>>>> >>>>> On Wednesday, October 31, 2012 7:48:56 AM UTC-4, Alexey Kupershtokh >>>>> wrote: >>>>>> >>>>>> Here it is: >>>>>> https://github.com/**AlexeyKupershtokh/node-candle<https://github.com/AlexeyKupershtokh/node-candle> >>>>>> >>>>>> it's similar to: >>>>>> https://github.com/coolaj86/**futures/tree/v2.0/future<https://github.com/coolaj86/futures/tree/v2.0/future> >>>>>> and >>>>>> https://github.com/temsa/**addTimeout<https://github.com/temsa/addTimeout> >>>>>> to some extent, except that the callbacks are able to free in my case >>>>>> allowing to avoid leaks. >>>>>> >>>>>> As an yet another example, if you use a callback wrapped by >>>>>> addTimeout(timeout, cb) or future.once(cb).setTimeout(**timeout) as >>>>>> an ACK callback for a socket.io request that is never acknowledged, >>>>>> this wrapepd callback would exist till the socket is disconnected. >>>>>> >>>>>> Any response is highly appreciated. >>>>>> >>>>> -- > 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
