RFR: SSLSocket HandshakeCompletedListeners are run on virtual threads

[Alan Bateman]

On 16/09/2020 14:30, Carter Kozak wrote:
>
> 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?
>
Yes, it would be good to restart the discussion and also re-verify that 
the API is actually useful, esp. with the potential for the session to 
be stale when listener is notified. If the interesting cases are 
monitoring or logging then maybe there are alternatives to explore.

-Alan