Improved locking for HttpReceiver.ContentSource.

[sbordet]

Improved response failure code path.
Now either responseFailure() must be called, or exchange.responseComplete() followed by HttpReceiver.abort().

Fixed failAndClose() for HTTP/2 and HTTP/3: the connection must not be closed, stream.reset() is sufficient.

Fixed flaky test HttpClientDemandTest.testTwoListenersWithDifferentDemand().

Fixed DistributionTests.testVirtualThreadPool().

Signed-off-by: Simone Bordet [email protected]

[gregw]

Either take semantic is needed or better comment to explain why not.

[gregw]

Given the comment/test below, it feels like this should be a takeHttpExchange() semantic, or at least the test below could be:

if (exchange == null || !disassociate(exchange))

At the very least, can the comment below explain how the race of exchange becoming null just after the get is handled?

[sbordet]

@gregw I don't understand.
The semantic cannot be "take", as the "take" happens later when also the request is completed.
The call exchange.responseComplete() is atomic, so the decision of whether doing something or not is taken there.

[gregw]

@sbordet It is a general pattern for a race to have code in an async environment that does non atomic test and then act. It may well be that the exchange is atomically "taken" and nulled elsewhere, but a thread here may still have tested the exchange whilst non null and then act on it whilst it is null.

So either this is a race here, or there is some external circumstance that ensures that the responseComplete can never be called between the test and the action. So we need to either fix the race or document why it is not a race.