Clarify Win32 handle validity

[notgull]

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 https://github.com/rust-windowing/winit/pull/3593

[Lokathor]

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]

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]

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]

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.

[notgull]

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]

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]

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