code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile
littlee at linux.vnet.ibm.com
Tue Nov 1 07:57:35 PDT 2011
On 11/01/2011 10:46 PM, Seán Coffey wrote:
> Yes - all three streams will now be closed. Previous to 7082769, when
> any of the streams calls close(), the underlying filedescriptor used
> get closed out via the native close0() call.
> A list of Closeables is maintained by FileDescriptor.
> On 01/11/2011 13:54, Charles Lee wrote:
>> On 10/29/2011 02:13 AM, Seán Coffey wrote:
>>> This is a second stab at cleaning up the close() and finalize()
>>> methods for FileInputStream / FileOutputStream / RandomAccessFile
>>> classes so that all parents/referents sharing the same native
>>> FileDescriptor are closed out correctly.
>>> With Alan's assistance, we have a better implementation in place
>>> where we avoid the use of counters and instead cycle through a list
>>> of shared closeables when a FileDescriptor is being shared.
>>> Bug report (not visible yet)
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/
>> Hi Sean,
>> If we have 3 FileInputStream which share the same FileDescriptor, and
>> one of the FileInputStream calls its own close. Will other 2
>> FileInputStream close?
>> I see fd.closeAll is called in the close of FileInputStream, I guess
>> it will close all the things which shared the same fd.
Does it change the original mechanism? IIRC, the original will remain
the other FileInputStream function well (can read from the under
stream), until the fd count become 0.
More information about the core-libs-dev