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