-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parallel transformations are run twice when one of the Futures resolves the other synchronously #367
Comments
It's might also be worth addressing why a user would want to exfiltrate the In the case of |
Will this issue be resolved, if rej and res functions are wrapped in a way that makes them idempotent? |
Hi @safareli :) No. Rej and res are already wrapped for idempotence: Lines 153 to 169 in f349eb4
The problem happens because the internal mechanics of |
It's built on the assumption that the userland of one Future doesn't trigger signals in the other. So the signals from the other future are not guarded while running the one Future. |
First discovered in fluture-js/fluture-hooks#6, this is one of several thinkable issues that arise once control over the resolution of a Future is taken outside of the Future constructor, for example:
The example above is very similar to what
fluture-hooks
does to achieve its parallel applicative instance. Arguably, this is not a bug, because the user is abusing Fluture: they're manually combiningm1
andm2
outside of Fluture's API for combining Futures. However, since it's possible to achieve this at all; I still want to record it as a bug and think about how Fluture should behave under these scenarios.The text was updated successfully, but these errors were encountered: