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!<p>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:<p>a) lets you use other Promise workflows to interact with them<p>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<p>among other goodies. Even if you're not working in the JS space, it's some really cool work to read about[1]<p>[1]<a href="https://github.com/getify/CAF" rel="nofollow">https://github.com/getify/CAF</a>
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.<p>If your promise lib has cancellation built in, then adding a timeout to one is easy.