On Mon, 21 Aug 2017 04:38:48 -0700, shoichik...@gmail.com wrote:
> This shows everytime we call bind-stdin method, the number of open
> files increases.
I've been able to confirm that the particular file handles being leaked
are the parent process's write uv_pipes towards the bound stdin. Obviously
the parent process does not need these filehandles anymore after building
a pipeline between children, but it ends up keeping them anyway.
I don't see anything else in the Proc::Async API that would help to close these
descriptors. The .close-stdin method demands that the (incompatible with
.bind-stdin) :w option has been supplied.
Internally, handles are fed to a uv_process_t. This libuv object has a
uv_close,
but not for particular filehandles... and I haven't used enough libuv to know
if that also kills the process. How this object actually stores these handles
is opaque, so we have no guarantee that we can reach in and grab the handles and
close them without causing re-use/async/signal issues.
Note that if we are (unlike in the example) interested in the output of the
whole pipeline, we would need to avoid also closing the stdout of the final
stage, and depending on libuv implementation this might be made tricky.
The Proc::Async class and its associated MoarVM backend are pretty convoluted
code
with lots of promises being handed about.,, as any async abstraction
implementation
is want to be. Also it is not that easy to work on from outside the core tree
given
highly restrictive encapsulation. So far I have not seen any indication of
anything
that is intended to clean up these particular filehandles. It might be as
simple as:
- @blockers.push($!stdin-fd.then({ $!stdin-fd := .result }));
+ @blockers.push($!stdin-fd.then({ $!stdin-fd := .result;
$!ready_promise := $!ready_promise.then({ # find and close the C filehandle and
alter the libuv object so it knows it was closed
})
...but that supposes a lot of things are safe to do which probably are not safe
to do.
