Emscripten/Javascript event loop support
- Dominant language
- C++
- Stars
- 21.5k
- Forks
- 3.5k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 2
Description
**Description**
Emscripten and/or Javascript code is mainly executed via event-loop, meaning they prefer non-blocking callback style of execution.
Blocking style of execution of catch2 is fine for simple things, but when interleaved with more sophisticated js functionality, it starts to breakdown.
To illustrate the problem, here is an example of mounting persistent file storage from emscripten:
static bool idbfsIsMounted = false;
EMSCRIPTEN_KEEPALIVE static void idbfsMountCallback()
{
idbfsIsMounted = true;
}
SCENARIO("Testing IDBFS", ...)
{
EM_ASM({
FS.mkdir('/idbfs');
FS.mount(IDBFS, {}, '/idbfs');
FS.syncfs(true, function (err) {
// this javascript callback can only be called when main function exits
// so in this example it is never called
// notify C++ code
Module.ccall('idbfsMountCallback');
});
});
while(!idbfsIsMounted) // deadlocks here
sleep(1s);
}
int main()
{
return Catch::Session().run(...);
}
Similar problem is encountered when trying to use sockets from tests, and many others.
The way how Catch2 session is implemented, I think it might be viable to add runOne() or pump() to the Session. And then Catch2 should give control back with some granularity. Doesn't solve this particular problem as-is though.
Another way to solve this might be to use https://emscripten.org/docs/porting/asyncify.html but that is only practical when compiling to WASM, as previous js target was very limited and slow when using asyncify.
Contributor guide
Assessment
This issue has not been assessed yet.