3 ms·
If someOtherpromise is an already resolved promise from your own library, then it will still take just 5ms - the neat hack here is that asap will simply push an
by spion 13y ago
If someOtherpromise is an already resolved promise from your own library, then it will still take just 5ms - the neat hack here is that asap will simply push another callback at the end of the queue (which is still being processed by the for loop) and the loop will simply get one more iteration straight in the middle of its execution.
If its from another library, then that other library may be using its own scheduler and you will loose those 5ms either way...
- lhorie 13y agoYep. I believe the bigger promise libraries (bluebird et al) implement mechanisms similar to asap internally iirc. My point was that violating the A+ spec instead of getting into the whole rabbit hole of timer clamps is not as unreasonable as one might think, and that doing so doesn't incur delays in any of those scenarios.
- spion 13y agoMaybe it isn't that unreasonable. But personally I do like guarantees, and in a stateful language I especially like guarantees about execution order. If these guarantees can be offloaded to a library then thats really great, as I don't have to keep them in mind anymore, freeing my brain to think about the specific problem I'm trying to solve. One less thing to check for when debugging too. There is also the bonus feature that stack overflows wont happen, which enables liberal use of recursive promise functions. (On the other hand, memory usage might still explode, so its not quite that easy... :D)
- lhorie 13y agoThose are good points. So far this approach hasn't been a problem w/ Mithril. If it turns out to be a bad idea down the road though, it can always be changed to conform w/ A+