Skip to content
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

Merged
merged 2 commits into from
Mar 24, 2024
Merged

Clarify Win32 handle validity #163

merged 2 commits into from
Mar 24, 2024

Conversation

notgull
Copy link
Member

@notgull notgull commented Mar 23, 2024

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

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 <dev@notgull.net>
@Lokathor
Copy link
Contributor

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.

@kchibisov
Copy link
Member

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.

@kchibisov
Copy link
Member

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.

@kchibisov
Copy link
Member

kchibisov commented Mar 23, 2024

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 <dev@notgull.net>
@notgull
Copy link
Member Author

notgull commented Mar 23, 2024

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 SetWindowSubclass function it explicitly says this:

Warning You cannot use the subclassing helper functions to subclass a window across threads.

@notgull
Copy link
Member Author

notgull commented Mar 23, 2024

By Rust's coherence rules, if a type is Send sometimes and !Send other times, it has to be !Send.

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.

I would guess that GL/Vulkan only uses the thread-safe parts.

@Lokathor
Copy link
Contributor

Lokathor commented Mar 23, 2024

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 Send is about is for fully safe stuff

@notgull notgull requested a review from Lokathor March 24, 2024 17:14
@notgull notgull merged commit afec0f2 into master Mar 24, 2024
4 checks passed
@notgull notgull deleted the notgull/clarify branch March 24, 2024 18:47
@notgull notgull mentioned this pull request Apr 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants