On Windows, only return the window handle if it is on the correct thread

[notgull]

On Windows, it is generally unsafe to use the HWND outside of the thread
that it originates from. In reality, the HWND is an index into a
thread-local table, so using it outside of the GUI thread can result in
another window being used instead, following by code unsoundness. This
is why the WindowHandle type is !Send. However, Window is Send and Sync,
which means we have to account for this.

Thus far the best solution seems to be to check if we are not in the GUI
thread. If we aren't, refuse the return the window handle.

---

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[Stehfyn]

Confirmed to operate as intended on windows

[kchibisov]

How does it behave with e.g. EGL where windows are Send(by the spec)? I guess it just creates and then the surface is being send to other thread, and the HWND itself is not touched during that?

[kchibisov]

This should link to docs on why it's like that.

[kchibisov]

Don't use deprecated API.

[notgull]

Is there a better way to create a closure application ad-hoc?

[madsmtm]

Not really, no. This would have to be done with ApplicationHandler:

struct App;
impl ApplicationHandler for App {
    fn new_events(&mut self, event_loop: &ActiveEventLoop, _cause: StartCause) {
        // Test code in here
    }
}

fn issue_3593() {
    let event_loop = EventLoop::new().unwrap();
    event_loop.run_app(App).unwrap();
}

I guess for the purpose of integration tests, we should probably have some sort of mechanism to do this more easily.

[msiglreith]

On Windows, it is generally unsafe to use the HWND outside of the thread
that it originates from. In reality, the HWND is an index into a
thread-local table, so using it outside of the GUI thread can result in
another window being used instead, following by code unsoundness.

Is there a reference for this somewhere?

[notgull]

Generally windows are thread unsafe unless otherwise specified. For instance, Raymond Chen says:

Informally, one says that the thread “owns” the window. Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it.

So HWNDs are !Send but Sync... except not really, since the main thread can set values and cause race conditions in the higher level threads.

From the raw-window-handle docs:

Users can safely assume that non-null/0 fields are valid handles, and it is up to the implementer of this trait to ensure that condition is upheld.

I'm saying that the definition of "valid" is "valid for the current context." As HWNDs are largely useless outside of the thread that they originate from, it is invalid to issue these handles outside of the origin thread.

[madsmtm]

CC rust-windowing/raw-window-handle#154 and rust-windowing/raw-window-handle#85 (comment), talk about making Win32WindowHandle !Send and !Sync (in the next breaking version of raw-window-handle).

[kchibisov]

I'd really like some confirmation from win32 docs/devs. Since the link is 20 years old, so maybe something changed or there's alternative.

[notgull]

@Stehfyn Can you comment here?

[msiglreith]

I can see HWND or a wrapper of it being !Send/!Sync in similar fashion as ptr.
I'm not agreeing on the thread-local argument, given one could also query it from another process for example and interact with it as it's rather an index into an OS managed array. Therefore, I also feel like we should artifically forbid access to it from another thread.

[kchibisov]

I mean how OpenGL/Vulkan then operate where every surface resource is Send between threads (by spec), and they build it from the HWND?

[notgull]

I mean how OpenGL/Vulkan then operate where every surface resource is Send between threads (by spec), and they build it from the HWND?

I've added a couple of escape hatches to allow for thread-safe usage. However for the default usage we should account for thread affinity

[kchibisov]

Given it just adds functionally, it should be good to go.