-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Implement emscripten_promise_race
in promise.h
#19154
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -462,6 +462,42 @@ static em_promise_result_t test_any(void** result, void* data, void* value) { | |
return EM_PROMISE_MATCH_RELEASE; | ||
} | ||
|
||
static em_promise_result_t test_race(void** result, void* data, void* value) { | ||
emscripten_console_log("test_race"); | ||
assert(data == (void*)7); | ||
|
||
em_promise_t in[2] = {emscripten_promise_create(), | ||
emscripten_promise_create()}; | ||
em_promise_t fulfill = emscripten_promise_race(in, 2); | ||
em_promise_t fulfill_checked = | ||
emscripten_promise_then(fulfill, expect_success, fail, NULL); | ||
emscripten_promise_destroy(fulfill); | ||
emscripten_promise_resolve(in[1], EM_PROMISE_FULFILL, (void*)42); | ||
emscripten_promise_resolve(in[0], EM_PROMISE_REJECT, NULL); | ||
emscripten_promise_destroy(in[0]); | ||
emscripten_promise_destroy(in[1]); | ||
|
||
in[0] = emscripten_promise_create(); | ||
in[1] = emscripten_promise_create(); | ||
em_promise_t reject = emscripten_promise_race(in, 2); | ||
em_promise_t reject_checked = | ||
emscripten_promise_then(reject, fail, expect_error, NULL); | ||
emscripten_promise_destroy(reject); | ||
emscripten_promise_resolve(in[0], EM_PROMISE_REJECT, (void*)42); | ||
emscripten_promise_resolve(in[1], EM_PROMISE_FULFILL, NULL); | ||
emscripten_promise_destroy(in[0]); | ||
emscripten_promise_destroy(in[1]); | ||
|
||
em_promise_t to_finish[2] = {fulfill_checked, reject_checked}; | ||
em_promise_t finish_test_race = emscripten_promise_all(to_finish, NULL, 0); | ||
|
||
emscripten_promise_destroy(fulfill_checked); | ||
emscripten_promise_destroy(reject_checked); | ||
|
||
*result = finish_test_race; | ||
return EM_PROMISE_MATCH_RELEASE; | ||
} | ||
|
||
static em_promise_result_t finish(void** result, void* data, void* value) { | ||
emscripten_console_logf("finish"); | ||
|
||
|
@@ -509,8 +545,10 @@ int main() { | |
em_promise_t test5 = | ||
emscripten_promise_then(test4, test_all_settled, fail, (void*)5); | ||
em_promise_t test6 = emscripten_promise_then(test5, test_any, fail, (void*)6); | ||
em_promise_t test7 = | ||
emscripten_promise_then(test6, test_race, fail, (void*)7); | ||
em_promise_t assert_stack = | ||
emscripten_promise_then(test6, check_stack, fail, NULL); | ||
emscripten_promise_then(test7, check_stack, fail, NULL); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if this kind of test that has many phases/sub-tests, would make sense written in gtest? I added one test recently that uses gtest, but perhaps it would be worth looking into using it more? Once downside is that its maybe a little heavy weight and relies heavily on C++ (so is not so good for testing low level C libraries perhaps?)> There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. gtest is great, but another problem for these tests in particular is that I don't think gtest would play well with the asynchrony happening here. The actual test checks for all of these tests aren't being run until well after |
||
em_promise_t end = emscripten_promise_then(assert_stack, finish, fail, NULL); | ||
|
||
emscripten_promise_resolve(start, EM_PROMISE_FULFILL, NULL); | ||
|
@@ -523,6 +561,7 @@ int main() { | |
emscripten_promise_destroy(test4); | ||
emscripten_promise_destroy(test5); | ||
emscripten_promise_destroy(test6); | ||
emscripten_promise_destroy(test7); | ||
emscripten_promise_destroy(assert_stack); | ||
emscripten_promise_destroy(end); | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,4 +28,7 @@ promise_any reasons: | |
42 | ||
43 | ||
44 | ||
test_race | ||
expected success: 42 | ||
expected error: 42 | ||
finish |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that it matters but I think you can drop the "2" here and below and have it inferred. Might make the code less readable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's true. I kind of like having the explicit visual marker where I can check that the declared size matches the size I pass to the API function, but I don't think it matters too much.