1) You want to start a process with static blob as stdin. In that case, you can use createRedirectedProcess, pass never as the input event but simply do the writing of the blob in the stdin-thread-initializer (called "handlers" here, although that is a bit confusing terminology in FRP context). The user needs to take care to fork the action that does the writing too, because it may block, and the initializer is run lifted into the network, so would block the network. This is awkward.
2) You want to pipe stdout from one process to stdin from another, without going through the network. Sure, you could take the stdout event and pass it as the stdin event, but this needlessly keeps the network busy. I am not sure if you could pass the stdout pipe created from the first process as a UseHandle when creating the second (hard to find documentation around this).
The only way I see to support such use-cases would be to expose more of the underlying process constructs. Although this might be out-of-scope for a library that is about reflex integration, maybe we can put this in an "internal" module.
I have started on a draft interface that supports the first use-case. I'll try to turn it into a PR sometime, feel free to ping me if I haven't yet and are interested in this.
Two examples:
1) You want to start a process with static blob as stdin. In that case, you can use
createRedirectedProcess
, passnever
as the input event but simply do the writing of the blob in the stdin-thread-initializer (called "handlers" here, although that is a bit confusing terminology in FRP context). The user needs to take care to fork the action that does the writing too, because it may block, and the initializer is run lifted into the network, so would block the network. This is awkward. 2) You want to pipe stdout from one process to stdin from another, without going through the network. Sure, you could take the stdout event and pass it as the stdin event, but this needlessly keeps the network busy. I am not sure if you could pass the stdout pipe created from the first process as aUseHandle
when creating the second (hard to find documentation around this).The only way I see to support such use-cases would be to expose more of the underlying process constructs. Although this might be out-of-scope for a library that is about reflex integration, maybe we can put this in an "internal" module.
I have started on a draft interface that supports the first use-case. I'll try to turn it into a PR sometime, feel free to ping me if I haven't yet and are interested in this.