3 ms·
> Should .then calls run on the calling thread if data was already available? This one hits close to home -- I remember being involved in a PR discussion for a
by Twisol 7y ago
> Should .then calls run on the calling thread if data was already available?
This one hits close to home -- I remember being involved in a PR discussion for a JavaScript promises library where this was hotly (iirc?) debated. What conclusion did you reach? (I was on the side of consistency -- .then should not run synchronously even if it could.)
- chadaustin 7y agoThat's one where we got lucky. We made the wrong decision, but it didn't matter because the distinction was invisible when using the higher-level abstractions (like coroutines) and combinators. My opinion now is that JavaScript does it right: `.then` should _always_ defer the callback. BUT, it does come at a real performance cost. And for code that is performance-sensitive and can handle the callback running immediately, the API should support a `.thenImmediate` or something that will run immediately if possible.
- kentonv 7y agoYes, JS got it right. It is very often the case that you need to consider different edge cases for synchronous vs. asynchronous execution, and it's very hard to cover both cases in tests, leading to code that randomly breaks in production based on timing differences, which is pretty much the worst.