Implement emscripten_promise_race in promise.h - #19154
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
8a0f9f7 to
1814020
Compare
This function propagates the result of its first input promise to settle, whether it is fulfilled or rejected.
|
@sbc100 this should be ready to go. |
| emscripten_console_log("test_race"); | ||
| assert(data == (void*)7); | ||
|
|
||
| em_promise_t in[2] = {emscripten_promise_create(), |
There was a problem hiding this comment.
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.
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.
| 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.
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.
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 main returns.
2 participants
Implement
emscripten_promise_racein promise.hThis function propagates the result of its first input promise to settle,
whether it is fulfilled or rejected.
update library sig file