Non deterministic order of promise resolution #110
Labels
Milestone
Comments
dlespiau
added a commit
that referenced
this issue
Mar 5, 2019
We want the js author to be able to rely on deterministic order of promise resolution to avoid surprises and generate non-determinitic configuration. We do this by making the order of promise resolution be the same as promise resolution, serializing the deferred goroutines before they re-enter v8 to resolve the promises. Fixes: #110
dlespiau
added a commit
that referenced
this issue
Mar 5, 2019
We want the js author to be able to rely on deterministic order of promise resolution to avoid surprises and generate non-determinitic configuration. We do this by making the order of promise resolution be the same as promise resolution, serializing the deferred goroutines before they re-enter v8 to resolve the promises. Fixes: #110
dlespiau
added a commit
that referenced
this issue
Mar 5, 2019
We want the js author to be able to rely on deterministic order of promise resolution to avoid surprises and generate non-determinitic configuration. We do this by making the order of promise resolution be the same as promise resolution, serializing the deferred goroutines before they re-enter v8 to resolve the promises. Fixes: #110
dlespiau
added a commit
that referenced
this issue
Mar 5, 2019
We want the js author to be able to rely on deterministic order of promise resolution to avoid surprises and generate non-determinitic configuration. We do this by making the order of promise resolution be the same as promise resolution, serializing the deferred goroutines before they re-enter v8 to resolve the promises. Fixes: #110
dlespiau
added a commit
that referenced
this issue
Mar 5, 2019
We want the js author to be able to rely on deterministic order of promise resolution to avoid surprises and generate non-determinitic configuration. We do this by making the order of promise resolution be the same as promise resolution, serializing the deferred goroutines before they re-enter v8 to resolve the promises. Fixes: #110
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If we fire two
std.read,jkwill currently start two goroutines and the first goroutine to finish will signal the promise as resolved. It means promise resolve functions can be called in any order.In turns, it opens many non-deterministic behaviour if the promise resolve functions act on a global state: mutate global or captured variables, call the random generator, ...
One possible way to make this a lot better is to resolve the promise in the order they came in. Ensuring the resolve functions are always called in the same order. This depends a bit on the v8 internals and on what happens when a promise is resolved. Need a bit more digging (and a test!)
The text was updated successfully, but these errors were encountered: