Re: Patch: close I/O channels when a process ends

[David Daney <ddaney at avtrex dot com>]

Andrew Haley wrote:
> David Daney writes:
>  > Tom Tromey wrote:
>  > >>>>>>"Andrew" == Andrew Haley <aph@redhat.com> writes:
>  > > 
>  > > 
>  > > Andrew> I ran out of file handles.  Was there any reason we weren't
>  > > Andrew> closing the files in Process.waitFor?
>  > > 
>  > > It probably isn't valid to do this.
>  > > Couldn't there still be data in the OS' pipe buffer?
>  > > 
>  > > Tom
>  > 
>  > My patch that is waiting for approval is an almost total rewrite of
>  > natPosixProcess, so would replace this.  However it would not solve the
>  > problem either.
>  > 
>  > I think that the place to fix this is in
>  > FileInputStream/FileChannelImpl.  When you get end-of-file when reading
>  > a pipe/file, you should close the descriptor there.
> 
> But we can still close the output channels here, can we?
> 

The only thing that I think is safe would be the following:

For each of inputStream and errorStream, when the Process terminates if
the corresponding get[InputStream|ErrorStream]() has not been called AND
 there are no bytes available, we can safely assume that no more data
will be coming.  Only if these conditions are met can you close the
streams.  However after closing the streams, you must replace them with
dummy streams that always return EOF.

Likewise for the outputStream, if getOutputStream() has not been called,
you can close the stream and replace it with a dummy stream that always
throws IOException.

If this sounds reasonable, I can integrate this into my PosixProcess
patch which can be found at:

http://gcc.gnu.org/ml/java-patches/2004-q3/msg00452.html

Opinions?

David Daney