On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Not really, it is the state we set when the virtual thread is mounted and >> runs again. In this case it will just run to re-contest for the monitor. > > So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: > > RUNNING -> BLOCKING -> BLOCKED > BLOCKED -> UNBLOCKING -> RUNNABLE > > I'm just trying to get a better sense of what we can infer if we see these > "transition" states. We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084
