code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile
Charles Lee
littlee at linux.vnet.ibm.com
Tue Nov 1 14:57:35 UTC 2011
On 11/01/2011 10:46 PM, Seán Coffey wrote:
> Charles,
>
> 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.
>
> regards,
> Sean.
>
> 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)
>>> http://bugs.sun.com/view_bug.do?bug_id=7105952
>>>
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/
>>>
>>> regards,
>>> Sean.
>>>
>>>
>> 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.
--
Yours Charles
More information about the core-libs-dev
mailing list