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
I'm testing this library for use in a workflow that involves piping multiple processes together (something I wish this library supported internally, where it could probably be done more efficiently - without having to copy ByteBuffers - though presumably this is zero-copy with direct ones - in order to avoid holding references to NuProcess's output buffers), including complex output handling, and occasionally piping one process to more than one output process, or observing the output from within the Java process.
One issue with creating workflows like this is this: Say I'm piping process A's stdout to process B's stdin.
I launch B, then A. A caches buffers into a ConcurrentLinkedDeque, which, B will read from when onStdInReady() is called.
However, onStdinReady() is called before any data is available, and even if it returns true, which should result in it's being called again, if no data is written to the passed buffer, it is not called again. The only solution I've found is to block in onStdinReady() until the first buffer is available. Which kind of defeats the purpose of using a non-blocking library for this stuff. But more seriously - and I haven't dug into the code deeply enough to determine this - if the thread pool used is the one created in the static block at the top of LinuxProcess, then there are only numProcessors threads available - once there are as many of these blocked as there are cores, there will be no threads to collect output.
See the example code below (it uses wav2png and sox to read an audio file into 16-bit integer wav format and generate a thumbnail from it). If you remove the call to waitForFirstWrite.await(), no output will ever be written to wav2png.
I'm testing this library for use in a workflow that involves piping multiple processes together (something I wish this library supported internally, where it could probably be done more efficiently - without having to copy ByteBuffers - though presumably this is zero-copy with direct ones - in order to avoid holding references to NuProcess's output buffers), including complex output handling, and occasionally piping one process to more than one output process, or observing the output from within the Java process.
One issue with creating workflows like this is this: Say I'm piping process A's stdout to process B's stdin.
I launch B, then A. A caches buffers into a ConcurrentLinkedDeque, which, B will read from when
onStdInReady()
is called.However,
onStdinReady()
is called before any data is available, and even if it returns true, which should result in it's being called again, if no data is written to the passed buffer, it is not called again. The only solution I've found is to block inonStdinReady()
until the first buffer is available. Which kind of defeats the purpose of using a non-blocking library for this stuff. But more seriously - and I haven't dug into the code deeply enough to determine this - if the thread pool used is the one created in the static block at the top ofLinuxProcess
, then there are only numProcessors threads available - once there are as many of these blocked as there are cores, there will be no threads to collect output.See the example code below (it uses wav2png and sox to read an audio file into 16-bit integer wav format and generate a thumbnail from it). If you remove the call to
waitForFirstWrite.await()
, no output will ever be written towav2png
.The text was updated successfully, but these errors were encountered: