On Mon, 28 Nov 2022 15:47:48 GMT, Jaikiran Pai <[email protected]> wrote:
> Coming to the part `#1` change - so it appears that we now maintain a state > if the selector manager thread doesn't start (i.e. fails in the rare case > where `Thread.start()` throws Exception). We consider the selector manager to > be alive in such cases. But this "aliveness" is only used for reference > tracking. I think, if the selector manager thread has failed to start, that > would mean the `HttpClient` instance cannot function, isn't it? But as far as > I can see it wouldn't start throwing up errors but would silently accumulate > requests (I'm using the term `requests` loosely here, but I mean the internal > `AsyncEvent` instances). Did I read the code correctly? If so, should we be > somehow propagating this thread start failure as actual exceptions whenever > requests are issued? We don't consider the thread to be alive in this case, but we will consider that it has started. The combination started=true and alive=false means that it has finished running (in this degenerative case it has never run - as if run() had been a no-op) start() is called from within the HttpClientImpl constructor, so if Thread::start fails I don't think it will be possible to get such a client - since the constructor will throw. So it doesn't matter much anyway. ------------- PR: https://git.openjdk.org/jdk/pull/11294
