Diagnosing pre-main latency in a short-lived macOS child process while preserving its parent

What’s your actual goal here? You’ve described a very complicated system that ultimately boils down to this:

Query checks a synthetic target process’s identity using Security.framework and produces a fixed 28-byte result.

You could just as easily do that without the additional processes, so I suspect that isn’t the actual goal, but rather that there’s some bigger picture.

That matters because it seems like you’re micro-benchmarking the performance of posix_spawn, which isn’t a very useful activity. macOS has never been a speed demon (daemon :-) when it comes to starting new processes, and there aren’t really any optimisations you can apply to it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you, Quinn. You are right that my original post focused too heavily on the diagnostic machinery and did not explain the goal clearly.

The immediate goal is a reliable native process-identity check within an automated test workflow. If the check times out or cannot establish the identity, the workflow must not treat that as a successful verification. The target is synthetic in these tests.

The supervisor/watchdog/observer/query chain is our current test arrangement. I have not established that all of those process boundaries are necessary for the actual functionality. Preserving the chain was a constraint for comparing diagnostic runs with the original failing test, not a claim that this is the best production architecture.

Likewise, the 1000 ms deadline is an existing application/test requirement, not an expectation that macOS guarantees process startup within that time.

We are not trying to optimize posix_spawn itself. We are trying to understand whether the intermittent timeout points to a problem in our implementation or to a fragile design assumption: starting a fresh helper and completing the identity check within that deadline.

The successful instrumented runs showed substantial elapsed time before main(), but they did not establish the cause of the original failure.

Before collecting more traces, would you recommend first reconsidering the per-check helper process—for example, performing the check in an existing process or using a longer-lived helper? What functional or isolation requirements would you need us to clarify to assess that choice?

We have not changed the implementation or relaxed the existing acceptance criteria.

One important clarification after reviewing our original design and implementation: my previous reply omitted why the separate query process was introduced.

This is a controlled validation harness for a fixed native host, not a general-purpose process-identity service. The intended sequence is:

1. Observer creates the target using POSIX_SPAWN_START_SUSPENDED.
2. Before resuming it, Query checks dynamic code validity, the expected build identity, and the required runtime/library-validation status bits.
3. Observer resumes the target only after validating the complete result, observing stdout/stderr EOF, and confirming that Query exited successfully and was reaped.
4. Observer then checks the target’s fixed synthetic output and termination.

The goal is to observe these properties without modifying the host being validated. This is a limited diagnostic observation, not a claim of continuous protection or production authentication.

The separate Query process was introduced because the Security calls are synchronous: if a call blocks, Observer must remain able to handle cancellation, terminate Query and the still-suspended target, and perform bounded cleanup. Observer owns both children. An outer watchdog addresses Observer stalls, but does not guarantee descendant cleanup after a forced termination.

Therefore, moving the synchronous check directly into Observer’s supervision loop would lose an intended failure-isolation property unless another supported mechanism replaces it.

The existing 1000 ms query deadline is an application/test budget, not an OS guarantee. We have not established that this particular value is appropriate.

Given this more specific goal, is a disposable helper a reasonable isolation boundary, or would you recommend another supported design that preserves cancellation and bounded cleanup without relying on fast per-check process startup?

The immediate goal is a reliable native process-identity check within an automated test workflow.

OK. Who is checking whose identity here? Reading your second reply it sounds like you want Observer (the parent) to be checking Query (thi child). If so, you don’t need custom machinery for that. Rather, have Observer run Query with a launch requirement that ensures its identity.

The easiest way to construct these requirements is with the LightweightCodeRequirements framework. Once you have one you can apply it using the launchRequirement property on Process.

Annoyingly, the corresponding Posix spawn attribute is SPI )-: See here. If you’d like to stick with posix_spawn, I encourage you to file an enhancement request to make that API. And if you do that, please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"