Has anyone made a crate that adapts a child process's output for mio or tokio? I know mio can work with named pipes via mio-named-pipes, but some platform-specific heavy lifting is still needed to redirect a child process to a named pipe (particularly on Windows, where that's also conveniently the only way to asynchronously read a subprocess's stdout).
Has anyone else tried to asynchronously read a subprocess while running a TCP server?
Cool! Are there any examples of muxing a non-TCP future like this with a service meant for a TCP server (and possibly running it on multiple threads)?
I see TcpServer can do multiple threads, but it's not compatible with other futures like tokio-process, while Core doesn't have much on mixing futures & services, nor an obvious way to run a future on multiple threads.
Can you elaborate a bit on what you’re envisioning here? What does running a future on multiple threads mean to you?
I’ll note that there’s futures_cpupool - Rust, which gives you a futures API on top of a threadpool where you can submit arbitrary tasks. Not sure if that’s useful to you.
Well "running the future" in the sense meant here in the docs, but with multiple threads responding to IO, as TcpServer does. But that's secondary. I can live with 1 thread.
What I have to do, & can't figure out, is run a TcpListener & a non-TCP future like tokio-process on the same reactor. All the examples I can find (like this) only involve one TcpListener.
Current Core is both a reactor and the executor, so decoupling readiness monitoring and execution is not built-in. In addition, the futures that run on it have no special threading needs (ie no Send or Sync requirement). As such, a future on a reactor is really confined to it. You can start a Core per thread and get multiple event loops running. With the Tokio reform, there’s discussion about splitting the reactor and executor responsibilities so this will likely get easier.
You can join or select a tcp socket future and a tokio-process future and run the combo on the same reactor. But, Core::run returns when the future given to it resolves. In the TcpListener case that future usually never resolves - it’s essentially an infinite loop of accept calls. In the tokio-process case I guess it depends on when the proc completes, which is usecase dependent of course.
In your scenario, how do the tcp and process pipelines interact in the grand scheme of things?