you should read it: > In the case of CANDLE, the only thing remain after a callback is timed out OR DELETE()D
On Sat, Nov 10, 2012 at 10:35 AM, Alexey Kupershtokh < [email protected]> wrote: > 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
