You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows, Rokit is not able to handle the signals necessary to close its descendant processes because those signals do not exist in Windows.
Aftman handles this by putting processes in a "job", such that closing the ancestor process (aftman) closes all descendant processes. This has the downside of making it very hard to spawn a process that persists after aftman exits. Jobs are roughly equivalent to process groups on other OS, and it appears that Rust libraries which enable process groups use jobs on Windows.
Info about jobs on Windows
There is a Windows API parameter when creating a Job, JOB_OBJECT_SILENT_BREAKAWAY_OK which allows processes to break away from the job with the CREATE_BREAKAWAY_FROM_JOB option. This appears to be the intended solution on Windows for automatically closing descendant processes and allowing them to spawn separately from the group.
With this implemented, it would be straightforward to create a tools which intentionally break away from the job. This could include a small exe which just spawns a new process separate from the job.
I would consider leaving these zombie processes to be a major usability issue! I regularly have to open up task manager to force kill the lingering rojo from closed VS Code windows so that it releases the port.
The easiest solution here for most users would be an option in rokit.toml which allows breaking away from the job. Maybe this could look something like
If process jobs are used to fix this usability issue, it would be nice if JOB_OBJECT_SILENT_BREAKAWAY_OK was set, but it would not be a priority if we had a per-tool option to spawn the tool outside of the job.
The text was updated successfully, but these errors were encountered:
I made a PR to migrate to using jobs on Windows #23 . This should fix the zombie processes for now with the same behavior as Aftman / Foreman. I think having an option in the manifest for this in the future is a good idea so I'll re-label this issue and we can keep it open 👍
filiptibell
changed the title
On Windows, Rokit leaves processes sticking around in cases where aftman does not
Add an option to spawn a process that persists even after Rokit exits on Windows
Jun 13, 2024
On Windows, Rokit is not able to handle the signals necessary to close its descendant processes because those signals do not exist in Windows.
Aftman handles this by putting processes in a "job", such that closing the ancestor process (aftman) closes all descendant processes. This has the downside of making it very hard to spawn a process that persists after aftman exits. Jobs are roughly equivalent to process groups on other OS, and it appears that Rust libraries which enable process groups use jobs on Windows.
Info about jobs on Windows
There is a Windows API parameter when creating a Job, JOB_OBJECT_SILENT_BREAKAWAY_OK which allows processes to break away from the job with the CREATE_BREAKAWAY_FROM_JOB option. This appears to be the intended solution on Windows for automatically closing descendant processes and allowing them to spawn separately from the group.
CREATE_BREAKAWAY_FROM_JOB is straightforward to set via Command.creation_flags but JOB_OBJECT_SILENT_BREAKAWAY_OK is not straightforward to set as there is no stdlib or package which enables setting it. The closest appears to be win32job, which assigns the appropriate struct, but does not include the ability to set this limit in its impl for the extended info struct.
With this implemented, it would be straightforward to create a tools which intentionally break away from the job. This could include a small exe which just spawns a new process separate from the job.
I would consider leaving these zombie processes to be a major usability issue! I regularly have to open up task manager to force kill the lingering
rojo
from closed VS Code windows so that it releases the port.The easiest solution here for most users would be an option in
rokit.toml
which allows breaking away from the job. Maybe this could look something likeIf process jobs are used to fix this usability issue, it would be nice if JOB_OBJECT_SILENT_BREAKAWAY_OK was set, but it would not be a priority if we had a per-tool option to spawn the tool outside of the job.
The text was updated successfully, but these errors were encountered: