Description
This function returns a ProcessIdentifier, which on Unix is a pid and on Windows is a numeric process identifier. Similar to #92, there is a Windows-specific race condition here. On Unix the pid will be valid until someone waitid's it. But on Windows the ProcessIdentifier may already be invalid by the time runDetached returns.
Should we consider an API change to return a different type like DetachedProcessIdentifier which would provide access to the underlying HANDLE? and would NOT be Codable, unlike ProcessIdentifier. This would still fulfill the API contract that the caller is responsible for freeing the subprocess resources and monitoring any state, but you need the original HANDLE to be able to do that without race conditions.
Marking as blocker because I think the question needs to be resolved before the API becomes immutable.
--
One approach could be to have runDetached return an Execution, and make the processHandle property I'm adding in #93, public instead of internal. That way we don't need to introduce new types.