RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now synchronize on packet [v2]

[Daniel Fuchs]

On Tue, 19 Nov 2024 14:58:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DatagramPacket isn't specified to be tread safe but as with many JDK 1.0 era APIs, all methods are synchronized. I think your question is about lock ordering as I/O operations require a read or write lock. This isn't specified anywhere but the implementation works consistently to avoid deadlock when using the APIs. If something synchronizes on a DatagramPacket then it would delay, maybe indefinitely, a send or receive op. So I think your concern is whether it might delay, maybe indefinitely, other send or receive operations with other datagram packages, right? I don't mind changing it. Arguably this would give us closer to what was there before JEP 373 although the legacy implementation didn't correctly coordinate concurrently usage beyond that.

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).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2488972803