On Wed, 16 Sep 2026 02:27:02 GMT, David Holmes <[email protected]> wrote:
>>> Can you clarify please when/where the old `is_vthread_mounted()` would >>> change, compared to where the value of `vthread()` changes in >>> `VirtualThread::mount/unmount`. I'm concerned the time windows for these >>> two methods of detecting a mounted virtual thread may differ in a >>> detectable way. For printing it likely does not matter but for the snapshot >>> are we satisfied that both queries would always return near-enough the same >>> result (naturally they must differ in the case where the existing check >>> would crash). >>> >> On mount, `vthread()` changes in `setCurrentThread`, right before calling >> `enterSpecial` which mounts the continuation (sets `_cont_entry`). At >> unmount we unmount the continuation first (unset `_cont_entry`) and then >> change `vthread()` back in `setCurrentThread`. >> This API only works for platform threads, but it doesn’t execute a handshake >> against the target, so the old `is_vthread_mounted` to check if there is a >> mounted vthread is unsafe and can crash. We still have the issue where the >> information reported might not be consistent, that’s why ideally this should >> use a handshake. > >> We still have the issue where the information reported might not be >> consistent, that’s why ideally this should use a handshake. > > Wouldn't a `MountUnmountTransitionDisabler` be a simpler way to get stability > here? Not that I think we really need it in this case. @dholmes-ora @pchilano Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32788#issuecomment-5691518365
