Implement asyncify-free vforking #5980

zebreus · 2025-12-16T16:47:05Z

// TODO: Review copilot PR description

This pull request adds support for a new proc_vfork syscall and refactors the vfork implementation to handle both asyncify and non-asyncify cases more robustly. The changes ensure that vforked processes that do not use asyncify are managed correctly, and the code now distinguishes between these two execution paths. Additionally, the vfork data structure and related syscalls are updated to support this distinction.

Vfork syscall support and handling:

Added a new proc_vfork syscall implementation in proc_vfork.rs, allowing vfork without stack rewinding (asyncify) and updating the environment and process management accordingly.
Registered the new proc_vfork syscall in both the 32-bit and 64-bit WASIX exports, making it available to WASI modules.
Updated the module exports in mod.rs to include the new proc_vfork implementation.

Vfork data structure and asyncify handling:

Changed the WasiVFork struct's rewind_stack field to be an Option<BytesMut>, allowing for cases where asyncify is not used.
Updated proc_fork to set rewind_stack as Some(...), and updated all vfork-related code paths to handle the Option type, including proper handling of the non-asyncify path in proc_exit and proc_exec3.

Process management improvements:

Ensured that when a vforked process is terminated or exec'd, the code properly checks if asyncify is used and avoids stack rewinding if not, improving stability and correctness in non-asyncify scenarios.

Minor improvements:

Added comments and TODOs for restoring store data (globals) in the non-asyncify vfork path, indicating areas for future enhancement.
Ensured the vfork handle is pushed to owned_handles for correct resource tracking.

These changes collectively improve the robustness and flexibility of process creation and management in WASIX, especially around the vfork syscall and its interaction with asyncify.

Copilot

Pull request overview

This pull request introduces support for a new proc_vfork syscall that enables vforking without requiring asyncify stack rewinding. The implementation distinguishes between asyncify and non-asyncify vfork execution paths by making the WasiVFork::rewind_stack field optional, allowing the system to handle both cases appropriately.

Key changes:

Added new proc_vfork syscall that sets rewind_stack to None, enabling vfork without asyncify
Modified WasiVFork struct to use Option<BytesMut> for rewind_stack field instead of requiring it
Updated proc_exit and proc_exec3 to handle non-asyncify vfork paths with early returns when rewind_stack.is_none()

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
lib/wasix/src/syscalls/wasix/proc_vfork.rs	New syscall implementation for asyncify-free vforking; captures store snapshot but omits rewind stack
lib/wasix/src/syscalls/wasix/proc_fork.rs	Updated to wrap `rewind_stack` in `Some()` to match the new `Option` type
lib/wasix/src/syscalls/wasi/proc_exit.rs	Added early return path for non-asyncify vfork before unwrapping rewind_stack
lib/wasix/src/syscalls/wasix/proc_exec3.rs	Added pattern matching to handle non-asyncify vfork path before attempting stack rewind
lib/wasix/src/syscalls/wasix/mod.rs	Registered new `proc_vfork` module in exports
lib/wasix/src/lib.rs	Updated `WasiVFork` struct documentation and added `proc_vfork` to 32-bit and 64-bit exports
lib/wasix/src/bin_factory/exec.rs	Updated `resume_vfork` condition to handle non-asyncify case as an error in unexpected exit scenarios

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.