-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify Win32 handle validity #163
Conversation
This commit clarifies what is expected by the system for a Win32 handle. It is expected that the Win32 handle belongs to the current thread. This is not a breaking change as it was previously necessary for the window to be considered "valid". cc rust-windowing/winit#3593 Signed-off-by: John Nunley <[email protected]>
I feel like there are situations where you can send HWND between threads, but we can probably ignore them in general and so say that we expect handles to be for the current thread. |
I still haven't got any link to where you're coming from, most stuff online suggests that it's safe to interact with HWND from multiple threads, since it's just a handle to the window. All the TLS stuff I've seen is irrelevant to and is in the context of some other stuff. The only issue is if you try to drop the resource, but it's a lifetime sort of thing. |
Keep also in mind that you can send gl surface and render off the main thread, e.g. see glutin's multi threaded example on windows, if HWND sending was not possible, then none of that ever rendered anything. |
e.g. this function is intended to be used off the main thread https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindowasync Also see https://learn.microsoft.com/en-us/windows/win32/winmsg/about-windows#multithread-applications and keep in mind that HWND is not a window, it's a reference, and you have functions to send messages to that window off the main thread or even broadcast to all windows created by process. |
Signed-off-by: John Nunley <[email protected]>
My main reference is Raymond Chen. Granted, it's not documentation; however given that he's maintained this blog since 2003 and has been heavily involved in the development of Win32 since its beginning, I'd argue it's just as good. In the docs themselves, for the
|
By Rust's coherence rules, if a type is
I would guess that GL/Vulkan only uses the thread-safe parts. |
Importantly, an end user "who knows what they're doing" can always override our estimations and force the value into another thread and use it there. It can become a problem if they do it wrong, but they're able to try if they want. What |
This commit clarifies what is expected by the system for a Win32 handle.
It is expected that the Win32 handle belongs to the current thread. This
is not a breaking change as it was previously necessary for the window
to be considered "valid".
cc rust-windowing/winit#3593