Investigate `AsyncStream` alternative for output streaming

[iCharlesHu]

Currently we rely on AsyncStream to bridge the "pull" based AsyncSequence consumer and "push" based DispatchIO (and soon epoll) producer. However, this could lead to the .unbounded buffer to grow infinitely if the consumer consumes slower than production. We should investigate an alternative

[weissi]

and soon epoll

Where are you intending to run the epoll? A new thread pool just for Subprocess? Or a new thread for each process? Neither sound ideal

[iCharlesHu]

and soon epoll

Where are you intending to run the epoll? A new thread pool just for Subprocess? Or a new thread for each process? Neither sound ideal

I'm still experimenting, but the current plan is to one new thread for the parent process (via static let singleton), so it doesn't grow with the amount of subprocess spawned.

[iCharlesHu]

After studying apple/swift-async-algorithms#305, I've come to the conclusion that unfortunately we simply can't make the read option "push-based" if we want to rely on DispatchIO. This is simply because no matter what kind of back pressure mechanism the stream itself implements, we can't translate that pressure to DispatchIO and ask it to slow down since it doesn't support back pressure itself (blocking the io handler is a no-go).

Instead of using an AsyncStream alternative, we simply just don't rely on AsyncStream and revert back to using withCheckedThrowingContinuation to fetch buffer chunk by chunk asynchronously.