Geal / serverless-wasm

MIT License
178 stars 9 forks source link

asynchronous IO #4

Open Geal opened 6 years ago

Geal commented 6 years ago

currently, TCP connections are blocking (ie, they block the whole interpreter). To have a server that handles reasonable load, we might need to have blocking IO on the wasm side, that translates to async IO on the host side. This is doable if we have a way to pause the interpreter (see https://github.com/paritytech/wasmi/issues/85) and start again once we get an event on the socket.

Geal commented 6 years ago

with fb872b70fd31050ba5db9 we have the beginning to get async IO working. The idea would be to handle a special case in function calls: https://github.com/Geal/serverless-wasm/commit/fb872b70fd31050ba5db90d6895388e5d7a39d2a#diff-6819af94d9e962b4dc7ef16cb532e1f2R68

In the case of external function call (ie not the nested case), if the function is asynchronous, it would return a custom error (a "trap") from invoke_context( https://github.com/Geal/serverless-wasm/commit/fb872b70fd31050ba5db90d6895388e5d7a39d2a#diff-6819af94d9e962b4dc7ef16cb532e1f2R66 ), and then the interpreter would keep the function stack and the function context instead of returning an error, and when we finally get the answer, we would update the context and then resume the interpreter