Make checkpoint/resume transparent to applications.

[losfair]

Motivation

With #489 and #567 , checkpoint/resume, migration, and OSR-based tier switching are now implemented. To make the process of checkpoint/resume completely transparent to applications, the environment also needs to be saved, and system calls need to be properly resumed from EINTR.

Proposed solution

Considering the complexity of different environments (WASI, Emscripten, etc.) starting from WASI would be a good choice.

• Add a check to the beginning of WASI functions that might invoke a blocking system call that whether this call is resumed from a previously interrupted call. If true, load the state before the interruption.
• Add a check after every blocking system call from WASI functions. If EINTR is returned in errno, notify the ckpt/resume runtime about the state that can be resumed in the future, and immediately return.
• Allow snapshotting WASI state (open files, etc.) to a binary format and resuming it independent of the previous system state.

[MarkMcCaskey]

Awesome, thanks for filing this issue.

I like the split in the proposed solution, we can do this over a couple of PRs.

We should have some discussions on exactly what state should be stored and how strict we should be with accepting the new state.

Also what are the time constraints? Is it valid for me to walk the file system that the WASI program has interacted with and store data at that point? Or should it already be cached in memory at that point?

The redundancy between the real FS and our representation of the FS is a bit tricky, especially in the context of other applications running on the system, modiyfing this global mutable state. I'm sure that future people at Wasmer (probably me) will have to deal with this. But I think we can safely delay worrying about this too much for at least a year

[Michael-F-Bryan]

Would this ability to checkpoint and resume execution be available to the code being executed? Either by some sort of intrinsic, or maybe the environment could provide a host function that returns a particular trap?

The use case I have in mind is to use WASM as a sandboxed environment for running (sequential) code, and being able to multitask between 10s or 100s of threads of execution concurrently. Kinda like green threads.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Feel free to reopen the issue if it has been closed by mistake.