code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile
sean.coffey at oracle.com
Wed Nov 2 09:18:17 UTC 2011
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)
>> 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.
More information about the core-libs-dev