Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to spawn a process that persists even after Rokit exits on Windows #22

Open
Corecii opened this issue May 8, 2024 · 1 comment · Fixed by #23
Open
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@Corecii
Copy link
Member

Corecii commented May 8, 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 like

[tools]
open-rbx = { target = "upliftgames/[email protected]", persist = true }

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.

@filiptibell filiptibell added the bug Something isn't working label May 8, 2024
@filiptibell
Copy link
Collaborator

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 filiptibell reopened this Jun 9, 2024
@filiptibell filiptibell added enhancement New feature or request help wanted Extra attention is needed and removed bug Something isn't working labels Jun 9, 2024
@filiptibell 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants