You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Two examples:
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.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.
The text was updated successfully, but these errors were encountered: