On Sun, 6 Sep 2026 23:12:54 GMT, David Holmes <[email protected]> wrote:
> To me this is a bug in the application as it is making unreasonable > assumptions about what it can do in the atexit handler (blocking in such > handlers is a "Bad Idea" (TM)). I had the same reaction at first, but this is apparently something Mesa does for its worker threads [1], [2]. If an FFM upcall stub is registered as a debug callback using [`glDebugMessageCallback`](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDebugMessageCallback.xhtml), it may be invoked on one of these worker threads, and they end up being attached to the JVM when the upcall happens. > But I suspect there may be other potential races/deadlocks possible when the > application operates this way. Right, this patch for instance doesn't prevent a race between a thread shutting down the JVM and another thread trying to join an attached thread. The joining thread might see the VM is not shut down yet and continue into `DetachCurrentThread` only for the VM to be shut down by the time it gets to `block_if_vm_exited`. This patch only helps cases where a join always happens after the JVM has already shut down. [1]: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/u_queue.c?ref_type=heads#L74 [2]: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/u_queue.c?ref_type=heads#L512 ------------- PR Comment: https://git.openjdk.org/jdk/pull/32686#issuecomment-5572403519
