Skip to content
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

Bysyncify: async transform for wasm #2172

Merged
merged 64 commits into from Jun 15, 2019

Conversation

Projects
None yet
2 participants
@kripken
Copy link
Member

commented Jun 14, 2019

This adds a new pass, Bysyncify, which transforms code to allow unwind and rewinding the call stack and local state. This allows things like coroutines, turning synchronous code asynchronous, etc.

The new pass file itself has a large comment on top with docs.

So far the tests here seem to show this works, but this hasn't been tested heavily yet. My next step is to hook this up to emscripten as a replacement for asyncify/emterpreter, see emscripten-core/emscripten#8561

Note that this is completely usable by itself, so it could be useful for any language that needs coroutines etc., and not just ones using LLVM and/or emscripten. See docs on the ABI in the pass source.

@gabrielcuvillier

This comment has been minimized.

Copy link

commented Jun 15, 2019

Sounds great, I'll try this with the Doom 3 port as a replacement for Emterpretify.

Also, that would maybe allow to have someday a blocking filesystem backend using IndexedDB, since neither FilesystemSync API and IndexedDBSync API are on the browsers vendors roadmap.
To me, having blocking I/O on (potentially big) persistent storage is THE missing feature of the Web platform actually. Well, at least, for porting legacy apps to the Web (having all the filesystem data in-memory is really a waste with huge app assets).

@kripken

This comment has been minimized.

Copy link
Member Author

commented Jun 15, 2019

@gabrielcuvillier this isn't quite ready! No emscripten integration yet, and hasn't been tested heavily. But hopefully next week I'll finish those things.

About IndexedDB synchronously, something like that is already available with the emterpreter, see https://emscripten.org/docs/api_reference/emscripten.h.html#indexeddb (and I intend to make it work with bysyncify too).

@kripken

This comment has been minimized.

Copy link
Member Author

commented Jun 15, 2019

Initial testing looks good on emscripten, however, I need full coroutine support to really see. Landing this as a first step meanwhile.

@kripken kripken merged commit 1cd34c2 into master Jun 15, 2019

4 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@kripken kripken deleted the bysyncify branch Jun 15, 2019

@gabrielcuvillier

This comment has been minimized.

Copy link

commented Jun 16, 2019

Ok, no issue. I'll test as soon as it is ready.

Yes, I know about those synchrounous IndexedDB functions, they are working well but does indeed require the Emterpreter. In D3 the file loading operations are done very very deeply in the code (+ D3 implement a concept of virtual filesystem on top of .pak files, that are .zips of assets), and using Emterpreter at the file read operation require to have too much stuff in the emterpreter whitelist in the end... something like more than 100 functions (omg!) :/ The performance impact starts to be seen compared to a non emterpreter build (not speaking about compilaiton time:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.