RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now synchronize on packet [v2]
Alan Bateman
alanb at openjdk.org
Wed Nov 20 17:33:20 UTC 2024
On Wed, 20 Nov 2024 16:00:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:
> Correct - my concern is with lock ordering, and existing custom code that might have been written before JEP 373, and that might synchronize on DatagramPacket. I'm OK if you think it's better to keep all the synchro in DatagramChannelImpl, but since the methods that take a DatagramPacket are only called from the DatagramSocketAdaptor I was wondering if it would be more pertinent to synchronize on DatagramPacket from there (and bring it closer to pre JEP 373 implementation).
The read/write lock used by DatagramChannel is not exposed so the ordering is hard to observe. In any case, I think what we have in the PR aligns with the locking that has been there since JDK 1.0. That is, it does in synchronized (p) in DatagramSocketAdaptor.send/receive It's a bit icky as the blockingXXX methods needs to assert that the current thread holds the lock, and doing in blockingXXX would work the same (the difference is not observable).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2489181007
More information about the nio-dev
mailing list