RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v2]

[Volkan Yazici]

On Thu, 8 May 2025 13:53:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> It's not clear to me why each `ServerSocketChannel` needs a separate temporary directory for its socket file.

Each JMH thread needs its own socket file. If we share the socket file folder, the following operations become error-prone due to racy nature of parallel JMH execution:

1. Creation of the parent folder
2. Creation of socket files (names shouldn't conflict)
3. Deletion of the parent folder (Parent can only be deleted when all workers are finished and their associated socket files are removed.)

Following tickets were created due to such (some stable, some intermittent) errors:

- `NoSuchFileException` error reported in the ticket this PR is addressing
- [8350915: JMH: test SocketChannelConnectionSetup failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8350915)
- [8351601: JMH: test UnixSocketChannelReadWrite failed for 2 threads config](https://bugs.openjdk.org/browse/JDK-8351601)

To avoid all this, we create a dedicated socket folder for each socket of each JMH worker. The implemented nothing-shared approach renders synchronization redundant, and hence, avoids its racy pitfalls.

> Also, is it possible to combine the functionality of the `ServerSocketChannelHolder` defined in one of the tests, with this class?

`ServerUdsChannelHolder` simplifies the Unix domain (UD) socket termination complexity caused by *files* involved. `SocketChannelConnectionSetup` benchmark employs both IP and UD sockets. There `ServerSocketChannelHolder` is an adapter for the termination logic, delegating to `ServerUdsChannelHolder` for UD sockets. It is possible to extend `ServerUdsChannelHolder` to also accept IP sockets, but I doubt if it worth the added complexity. Would you like me to give that a try?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2081522745