I've been programming with promises for several years now, and I find myself using a common pattern of adding a race timeout promise. It seems like a useful feature, why isn't it implicit when dealing with deferred execution? I run into very few cases where an infinite timeout period makes sense.
You're not the only person to be asking this question recently!
Kyle Simpson (@getify on twitter and github) of You Don't Know JS fame has been working on a library for Javascript that wraps generators in a way that:
a) lets you use other Promise workflows to interact with them
b) lets you create a cancellation token that can be passed to a chain of asynchronous work to allow jobs to be cancelled all the way down that chain
among other goodies. Even if you're not working in the JS space, it's some really cool work to read about[1]
Well, you have to cancel the task, not ignore it. So you need some standard cancellation hook. And that generally has to be something explicitly handled by the task in question; it cannot automatically percolate all the way down to the deepest sub-task.
If your promise lib has cancellation built in, then adding a timeout to one is easy.
oh, shit. that means if i just send a timeout promise and a worker promise to Promise.race([...]), and the timeout finishes but the worker never does... then I have some unfulfilled promise hanging out somewhere indefinitely? I guess so... if I do Promise.race([p1, p2]) and p1 fulfills and p2 doesn't, p2 is still alive...indefinitely. Am I right or wrong...?
Kyle Simpson (@getify on twitter and github) of You Don't Know JS fame has been working on a library for Javascript that wraps generators in a way that:
a) lets you use other Promise workflows to interact with them
b) lets you create a cancellation token that can be passed to a chain of asynchronous work to allow jobs to be cancelled all the way down that chain
among other goodies. Even if you're not working in the JS space, it's some really cool work to read about[1]
[1]https://github.com/getify/CAF