Starting a process, in order to wait for another process, when the main process will still have to wait for the waiting process, is more than a little convoluted.

It also makes life difficult in that the main program doesn't have access to the pid of the subprocess it wants to run/monitor/control, only the pid for the waiting process that it doesn't really want.

threads certainly simplify the scenario, and despite the "deprecation", they still work fine, provided they are enabled at build time.

But, either way, often the simplest of all is to use the piped open, which is asynchronous and returns the pid of the process you want to control/monitor.

The only things to be careful of is if the process you're running produces a lot of output; in which case it will fill the output buffer and block until you read some data from the other end of the pipe periodically to prevent that.

It gets a little more complex if you need the output from multiple processes, as you need to multiplex that reading somehow. (Eg. IO::Select)

If you don't need the output, then redirecting it to null is a possibility, but that reintroduces the problem of the intermediate process (the shell to do the redirection).