Our current exit handling is fragmented across multiple components, which makes the shutdown path hard to reason about and difficult to maintain. At the moment, part of the exit logic is handled inside the cage struct, including tracking in-flight grate execution, while other parts of the exit path are handled by different components in a cross-dependent way. For example:
- cage contains cleanup logic,
- but that cleanup depends on Wasmtime grate execution having already finished,
- and cage also calls into other exit-related logic such as signal handling, cage_finalize, etc.
meanwhile, the 3i harsh_cage_exit path has not been successfully integrated into the overall design. This results in exit/shutdown responsibilities being split across multiple places, with overlapping control flow and duplicated invocation risks, as well as panicked at some grate scenarios.
Proposed direction
Cleanup in fdtables / cage must happen only after cage/grate execution has fully finished. I would like to split exit handling into two clearly separated phases:
Execution shutdown
All cage/grate execution shutdown logic should be fully encapsulated in Wasmtime-side functions.
Remove grate call count tracking from the cage struct.
Resource cleanup
All cleanup logic should be invoked from 3i::harsh_cage_exit.
The 3i table should first perform execution shutdown.
After execution has fully stopped, it should invoke cage / fdtables cleanup.
This should be able to avoid repeated or partially duplicated cleanup calls from multiple locations.
Planned work
The grate execution–related changes will be handled in PR #1061.
The remaining cleanup / integration work will be fixed in a new PR.
Our current exit handling is fragmented across multiple components, which makes the shutdown path hard to reason about and difficult to maintain. At the moment, part of the exit logic is handled inside the cage struct, including tracking in-flight grate execution, while other parts of the exit path are handled by different components in a cross-dependent way. For example:
meanwhile, the 3i harsh_cage_exit path has not been successfully integrated into the overall design. This results in exit/shutdown responsibilities being split across multiple places, with overlapping control flow and duplicated invocation risks, as well as panicked at some grate scenarios.
Proposed direction
Cleanup in fdtables / cage must happen only after cage/grate execution has fully finished. I would like to split exit handling into two clearly separated phases:
Execution shutdown
All cage/grate execution shutdown logic should be fully encapsulated in Wasmtime-side functions.
Remove grate call count tracking from the cage struct.
Resource cleanup
All cleanup logic should be invoked from 3i::harsh_cage_exit.
The 3i table should first perform execution shutdown.
After execution has fully stopped, it should invoke cage / fdtables cleanup.
This should be able to avoid repeated or partially duplicated cleanup calls from multiple locations.
Planned work
The grate execution–related changes will be handled in PR #1061.
The remaining cleanup / integration work will be fixed in a new PR.