8212132: (dc) Remove DatagramChannelImpl finalize method

[Martin Buchholz]

The Cleaner code looks good to me.

Of course, ensuring the concurrency correctness of this code is a much
harder problem.  I was especially frightened when I saw

1259         // wait for any read/write operations to complete before
trying to close
1260         readLock.lock();
1261         readLock.unlock();
1262         writeLock.lock();
1263         writeLock.unlock();
1264         synchronized (stateLock) {

I have come to think of GC finalization as yet another mutual exclusion
problem - between the object and the patient GC vulture waiting to collect
it and call its cleaner.

On Thu, Oct 24, 2019 at 7:23 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 23/10/2019 21:46, Alan Bateman wrote:
>
> On 23/10/2019 21:38, Martin Buchholz wrote:
>
>
> :
>
> You would call it like this:
> this.cleanable = CleanerFactory.cleaner().register(this, cleanerFor(fd));
> It's just moving code around, and only slightly safer/more disciplined.
>
> Okay, that might be a bit cleaner although it would be two static
> factories as the cleaning action is different for TCP vs. UDP.
>
> I've updated the proposed change to invoke the register method in the
> constructor. Also added the @requires to the test so that it is clearer
> that it doesn't run on Windows. I've left the check for
> UnixOperatingSystemMXBean in the test as I can't be sure that it can be
> obtained on some of exotic ports. The new webrev is here:
>
> http://cr.openjdk.java.net/~alanb/8212132/webrev.02/index.html
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191025/184a7d24/attachment.html>