RFR: SSLSocket HandshakeCompletedListeners are run on virtual threads

[Carter Kozak]

On Wed, 16 Sep 2020 10:44:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should re-start that discussion and get a conclusion on whether this will be changed or not.

I completely agree that running listeners on the completion thread would be ideal and allow the most flexibility for
consumers, but I'm worried that changing the behavior between java releases without a new API (perhaps an overload
which additionally takes an Executor instance) would cause too much friction for existing consumers. Listeners which
expect to execute long running operations would potentially cause performance regressions when taking a java release
including the change, which I'd imagine would make it a non-starter. Loom virtual threads provide the ability to
preserve existing behavior without the overhead incurred by OS threads. I'd be happy to start a thread to discuss a
mechanism to listen for handshake completion without dispatching to additional threads (virtual or otherwise), but I
think that would be a separate, parallel, change. What do you think?

> just need to drop inheritThreadLocals (the final parameter Thread constructor in TransportContext is false, meaning
> that inheritable thread locals are not inherited in the existing code)

Good catch, I got my wires crossed! Fixed.

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

PR: https://git.openjdk.java.net/loom/pull/16