[fuchsia] spawn child processes off main thread
As there are conditions under which spawning a child process could take an
extended period of time, it is desirable to perform the spawn off of the main
thread, so as to allow IO to continue (including SSH keepalives).
One such repro trigger is to run `k ut -r 100 brwlock` while trying to start
a new command via ssh. This will enter fdio_spawn on sshd's main thread,
which blocks on the debugcommand service in svchost for the duration of the
tests. The end result is that the ssh client times out due to lack of
response to keepalive, and once the tests finish, sshd will shutdown in
response to the client closing it's connection. The in-flight child process
most often then exits with ZX_ERR_PEER_CLOSED from it's loader service
channel, because sshd was hosting that channel, but has exited (which is all
essentially correct behavior). Other mechanisms to trigger these conditions
can be created, such as loading very large objects from blobfs from slow
storage backends or with slow or throttled CPUs. One such reproduction has
been demonstrated with very large Chrome based test binaries that blocked
appmgr in VmoFromFilenameAt, which was ultimately blocked by blobfs in
FileGetBuffer taking multiple seconds to read, decompress and verify the
blob.
This change does not address the root cause of these problems (synchronous
operations in critical system services), but it mitigates the user-observable
behavior of ssh connection loss during such events, at least for the process
spawning path which is commonly reported.
Additionally, instead of creating a new loader service for each child
process, we re-use a single loader service as configured during the async
loop initialization.
Test: ensure that spawns with and without tty work
Test: ensure that blocked process spawns do not cause connection loss
Bug: 34399
Change-Id: I496c59b19d4e1c16a079e96fdac95a939308e842
1 file changed
