I've been having a problem with the startProcess() implementation, namely to read/write stdout, stderr, stdin of the resulting process concurrently. E.g., if I want to exchange data bidirectionally through stdin/stdout of the child process or if both stdout and stderr can produce enough output to saturate their respective pipes.
I looked at simply doing it via multiple threads, but it appears as though PStream types cannot be properly sent through channels (and I don't think I understand storeAux() in system/channels.nim well enough to see why); the underlying file handles are not public, so I can't send those across a channel, and accessing stream objects in another thread's heap seems like a recipe for disaster.
The obvious solution would be to add a version of osproc.select() that allows you to poll more than just the stdout pipe of a process; that would be easy enough on Posix systems (just a bit more juggling of file descriptors, and I could probably put together an implementation in short order), but I'm simply not familiar enough with Windows internals to produce a solution for that OS (if it's even possible without major hackery).
A simpler option would be to expose the underlying file handles to modules importing osproc.
It would also probably be a good idea to allow a process to selectively redirect stdout and stderr to an existing file handle (e.g., the original stdout/stderr or /dev/null). Otherwise, without poStdErrToStdOut (say, because you don't want warning messages to pollute stdout) you'd always be at risk of deadlock if the stderr pipe fills up. The poParentStreams option can only do that wholesale.
That works, though you have to send the process object before creating the streams (at least on Posix systems).
Anyhow, I'll go expose the file handles and submit a pull request. Do you just want the handles to be made public or separate accessor procedures for them (including documentation, naturally)?