code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

[Seán Coffey]

On 02/11/2011 06:35, Alan Bateman wrote:
> On 01/11/2011 09:47, Seán Coffey wrote:
>> :
>>
>> Are you referring to the parent.close() call ? If otherParents is 
>> null, then we only have one reference to this FileDesriptor - i.e the 
>> Stream that has called close().
> It's parent.close() that I'm wondering about. Suppose p1 is the 
> parent, p2 is in otherParents. If p2.close is invoked then it looks 
> like p1's close method will not be invoked, leaving p1 open and the 
> underlying file descriptor closed.
The parent gets added to the ArrayList when that ArrayList needs to be 
set up (more than 1 referent) so this shouldn't be a problem. When the 
ArrayList (otherParents) is non-null a close will be called on the 
stream that initiated the close operation (through recursion) - that 
should be a no-op at that stage though. (closed == true)

regards,
Sean.
>
>>
>> Any exception from releaser.close() becomes the main exception if one 
>> is seen there. Any exceptions from the earlier closes are then added 
>> as suppressed. I've run some tests on this and it looked to work as 
>> expected. (stack trace below)
> In this example then the IOException appears to be thrown suppressing 
> one exception. That suppression exception in turn suppresses two 
> others. I had expected that the primary IOException would have 
> suppressed three exceptions. As I said, in practical terms this is 
> much of a concern, just pointing out that it's not exactly as expected.
>
>> I used hg rm/add. I guess hg mv would have worked too.
> You need to use hg mv so that the history can be followed. Also webrev 
> handles it, at least before you create the changeset, so that you can 
> easily see the changes.
>
> -Alan.