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
> 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 ) 
>>> for node.js. More details and benchmarks are here - 
>>> 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
>>>>
>>>> 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
>>>>>
>>>>> it's similar to:
>>>>> https://github.com/coolaj86/futures/tree/v2.0/future
>>>>> and
>>>>> 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

Reply via email to