Post

Replies

Boosts

Views

Activity

Supported OS-owned lifetime for one-shot macOS work after its controller exits
I’m designing a macOS utility that needs to run a bounded, one-shot diagnostic and collect its result. The lifetime problem is: A controller asks for the diagnostic to start. The diagnostic may begin successfully. The controller can then fail immediately — potentially before it has retained the child’s PID or established output collection. The diagnostic may close stdin/stdout/stderr while continuing to run. The diagnostic must not become an unmanaged orphan if the controller disappears. A focused test case uses Foundation.Process: Controller launches Child. Controller immediately exits with _exit(42), without waiting for Child or retaining its process identifier. Child calls setsid(), closes stdin/stdout/stderr, stays alive for up to 120 seconds, then exits. What I’m trying to establish is the supported macOS lifecycle boundary, rather than inventing a cleanup scheme around PIDs. Is there a supported per-user launchd or other OS-managed mechanism where the OS assumes responsibility for the job before the diagnostic process can start, such that the requesting controller may subsequently fail without leaving an unmanaged process? Specifically: At what point does the OS own the lifetime relative to registration and process creation? What supported mechanism bounds or terminates the job if the requesting controller disappears? Is there a supported hard execution-time limit, rather than an idle-time concept? How are descendants or process groups contained, and does calling setsid() conflict with that containment? What completion or failure information remains available to a later controller after the original requester has died? Are there important per-user, privilege, sandboxing, signing, or macOS-version limitations? I’m not reporting an Apple bug and I’m not asking for a custom recovery implementation. I’m trying to identify the documented supported lifetime mechanism and its guarantees and limitations before choosing an architecture. Environment: macOS 26.6.2 Apple silicon Foundation.Process is used by the focused reproducer Apple Developer Technical Support suggested I start a new thread for this specific question in Processes & Concurrency.
1
0
57
2h
Supported OS-owned lifetime for one-shot macOS work after its controller exits
I’m designing a macOS utility that needs to run a bounded, one-shot diagnostic and collect its result. The lifetime problem is: A controller asks for the diagnostic to start. The diagnostic may begin successfully. The controller can then fail immediately — potentially before it has retained the child’s PID or established output collection. The diagnostic may close stdin/stdout/stderr while continuing to run. The diagnostic must not become an unmanaged orphan if the controller disappears. A focused test case uses Foundation.Process: Controller launches Child. Controller immediately exits with _exit(42), without waiting for Child or retaining its process identifier. Child calls setsid(), closes stdin/stdout/stderr, stays alive for up to 120 seconds, then exits. What I’m trying to establish is the supported macOS lifecycle boundary, rather than inventing a cleanup scheme around PIDs. Is there a supported per-user launchd or other OS-managed mechanism where the OS assumes responsibility for the job before the diagnostic process can start, such that the requesting controller may subsequently fail without leaving an unmanaged process? Specifically: At what point does the OS own the lifetime relative to registration and process creation? What supported mechanism bounds or terminates the job if the requesting controller disappears? Is there a supported hard execution-time limit, rather than an idle-time concept? How are descendants or process groups contained, and does calling setsid() conflict with that containment? What completion or failure information remains available to a later controller after the original requester has died? Are there important per-user, privilege, sandboxing, signing, or macOS-version limitations? I’m not reporting an Apple bug and I’m not asking for a custom recovery implementation. I’m trying to identify the documented supported lifetime mechanism and its guarantees and limitations before choosing an architecture. Environment: macOS 26.6.2 Apple silicon Foundation.Process is used by the focused reproducer Apple Developer Technical Support suggested I start a new thread for this specific question in Processes & Concurrency.
Replies
1
Boosts
0
Views
57
Activity
2h