What if only one dies?

When one dies, it also kills the other

I think swapping to _processUtils.start with trace:true and setting up a mapFunction to process the XCDeviceEventNotification would give you the stdout/stderr behavior you want here, and would be cleaner.

It does most of what you need, but unfortunately returns a future to the exitCode and not the streaming process, so you won't be able to kill it as-written. You could add a streamProcess method to ProcessUtils that takes the same params, move all the stream logic into that, and return the process. Then make stream call streamProcess and return process.exitCode.

So I tried out _processUtils.stream (assuming that's what you meant), but it's a bit problematic because it waits for the stdout/stderr to be fully processed and then cancels the subscriptions.

I can't think of any great workarounds that maintain the current usage of ProcessUtils.stream and also work for my use case. Perhaps I could make a customized version of ProcessUtils.stream in xcdevice.dart and use that function?

it's a bit problematic because it waits for the stdout/stderr to be fully processed and then cancels the subscriptions.

Has "fully processed" means the process has already exited though?

From what I can tell by testing it yet, it waits for it to exit

From what I can tell by testing it yet, it waits for it to exit

Isn't that what you want then? I don't think you want those subscriptions to continue after the process is done. Your code is doing the same thing in _streamXCDeviceEventCommand.

    unawaited(process.exitCode.whenComplete(() {
      stdoutSubscription.cancel();
      stderrSubscription.cancel();
    }));

You're right that we don't want those subscriptions to continue after the process is done, which is why I have the unawaited you quoted. The difference, though, is that _streamXCDeviceEventCommand does not wait for the process to exit.

Here's a breakdown of the problem with _processUtils.stream:

So _processUtils.stream waits for the process to exit before returning:

So let's say I created _processUtils.streamProcess which returns the Process:

  Future<Process> streamProcess(
    args,
  }) async {
    final Process process = await start(
      args,
    );
    final StreamSubscription<String> stdoutSubscription = process.stdout
      [removed to shorten...]
    final StreamSubscription<String> stderrSubscription = process.stderr
      [removed to shorten...]

    // this is the problem-maker, it will get stuck waiting here
    await Future.wait<void>(<Future<void>>[
      stdoutSubscription.asFuture<void>(),
      stderrSubscription.asFuture<void>(),
    ]);

    unawaited(stdoutSubscription.cancel());
    unawaited(stderrSubscription.cancel());

    return process;
  }

Then, let's say I changed this to use _processUtils.streamProcess

_usbDeviceObserveProcess = await _processUtils.streamProcess( 
   args,
 ); 
  
  // This will not be reached until `_usbDeviceObserveProcess` is exited
 _wifiDeviceObserveProcess = await _processUtils.streamProcess( 
   args,
 ); 

In the above, _wifiDeviceObserveProcess will not be set until the _usbDeviceObserveProcess is exited, which isn't what we want. We want them to run simultaneously. Plus, hypothetically, these processes should run forever and never exit so it prevents it from listening for wifi connections because it's stuck there. Using unawaited to workaround it would also be problematic because _usbDeviceObserveProcess and _wifiDeviceObserveProcess are not actually set until they complete, which means they can't be killed

So _processUtils.stream waits for the process to exit before returning:

Ah, I get it. Thanks for explaining, I'm sure it's really obvious when you're stepping though it 🙂