breaking: Change thread safety guarantees for window types by notgull · Pull Request #192 · rust-windowing/raw-window-handle

notgull · 2026-02-22T22:00:35Z

In this commit, thread safety documentation is added for all window
handle types. In addition, following some additional research, some
window types have their thread safety changed. Most notably:

OHOS windows are definitely thread-unsafe.
Redox and Haiku windows are actually thread safe.
GBM types are Send but not Sync.
Win32 windows are Sync but not Send.
Display handles are changed to match their windows.

notgull · 2026-02-22T22:03:48Z

Poke:

@kchibisov for GBM handles.
@MarijnS95 for Android handles.
@hoanga for Haiku handles.
@jschwe for OHOS handles.
@jackpot51 for Redox handles.

I did some research and I think the conclusions I came to are correct, but I'd appreciate confirmation.

src/unix.rs

kchibisov · 2026-02-24T13:42:35Z

src/unix.rs

+/// ## Thread-Safety
+///
+/// GBM surfaces are not bound to a single thread; however, they are not
+/// internally secured by mutexes and cannot be used by multiple threads at
+/// once. Therefore this type is `Send` but not `Sync`. This means it can be
+/// sent to other threads but not used from other threads.


The gbm.rs crate defines them as Sync as well, but they wrap the pointers into Arc in the first place, which probably makes it Sync semantically? But Send is true.

I think this depends on the backend? Either way, I'd say we leave it as Send for now.

src/unix.rs

src/ohos.rs

madsmtm · 2026-02-28T05:50:17Z

src/appkit.rs

 /// # }
 /// ```
+///
+/// ## Thread Safety


Nit: This is already discussed a bit above the example, maybe merge these texts?

Same for UiKitWindowHandle.

Where would these texts be merged?

Either before or after the example, I don't mind either way.

Still not resolved

Please double check, I modified the AppkitDisplayHandle's docs to point to AppkitWindowHandle's docs.

Oh right, there's a paragraph I missed. Let me fix that.

madsmtm

I've looked at the backends I could, generally think this PR is a good change. We might want to refine the Windows stuff, but let's discuss that in #209.

src/android.rs

src/appkit.rs

src/uikit.rs

madsmtm · 2026-03-01T20:48:32Z

src/web.rs

+/// WASM objects are usually bound to the main UI "thread" belonging to the
+/// top-level webpage. Therefore this type is `!Send` and `!Sync`. It cannot be
+/// sent to or used from other threads.


CC @daxpedda on this.

madsmtm · 2026-03-01T20:49:45Z

src/windows.rs

+///
+/// ## Thread-Safety
+///
+/// Window handles have [thread affinity]. This means that they are `!Send`, as
+/// they must be dropped on the same thread that created them. However, some
+/// functions on the window can be called from other threads. This means that
+/// the window is `Sync`.
+///
+/// Note that not all functions of the Win32 handle are thread-safe (modifying
+/// functions especially), so care should be taken to not call these functions
+/// from other threads. When in doubt, only run the function on the main thread.
+///
+/// [thread affinity]: https://devblogs.microsoft.com/oldnewthing/20051010-09/?p=33843
 #[non_exhaustive]
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
 pub struct WinRtWindowHandle {
    /// A WinRT `CoreWindow` handle.
    pub core_window: NonNull<c_void>,
 }


Do you have docs that this really applies to WinRT too? I'd be worried that it might be more restrictive than Win32.

I think so? This document mentions that UI elements have "thread affinity". In addition I also recall reading somewhere that WinRT wraps around Win32 primitives internally.

In this commit, thread safety documentation is added for all window handle types. In addition, following some additional research, some window types have their thread safety changed. Most notably: - OHOS windows are definitely thread-unsafe. - Redox and Haiku windows are actually thread safe. - GBM types are Send but not Sync. - Win32 windows are Sync but not Send. - Display handles are changed to match their windows. Signed-off-by: John Nunley <dev@notgull.net>

kchibisov requested changes Feb 24, 2026

View reviewed changes

jschwe reviewed Feb 24, 2026

View reviewed changes

src/ohos.rs Outdated Show resolved Hide resolved

notgull force-pushed the notgull/thread-safety branch from 738e54b to 6bbce6b Compare February 28, 2026 01:10

madsmtm reviewed Feb 28, 2026

View reviewed changes

madsmtm mentioned this pull request Mar 1, 2026

Make Win32WindowHandle Send + Sync #209

Open

notgull force-pushed the notgull/thread-safety branch from 6bbce6b to d3e4910 Compare March 1, 2026 20:26

notgull requested a review from madsmtm March 1, 2026 20:29

madsmtm reviewed Mar 1, 2026

View reviewed changes

notgull force-pushed the notgull/thread-safety branch from d3e4910 to 2ff7b7d Compare March 1, 2026 22:09

notgull force-pushed the notgull/thread-safety branch from 2ff7b7d to ce693c8 Compare March 3, 2026 05:04

Conversation

notgull commented Feb 22, 2026

Uh oh!

notgull commented Feb 22, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

madsmtm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants