MacOS backend can trigger UB if a Window is transferred between threads then had functions on NSView called.

[goddessfreya]

As stated in the lengthy title, the MacOS backend can trigger UB if a Window is made from a non-main thread, or transferred between threads then had functions on NSView called. (Where the latter might not necessarily be happening, although I would not be suprized if it is, as I haven't looked too hard at the code.)

According to the cocoa docs:

Main Thread Only Classes

The following classes must be used only from the main thread of an application.

• NSView and all of its descendants. For more information, see NSView Restrictions.

NSView Restrictions

The NSView class is generally not thread-safe. You should create, destroy, resize, move, and perform other operations on NSView objects only from the main thread of an application. Drawing from secondary threads is thread-safe as long as you bracket drawing calls with calls to lockFocusIfCanDraw and unlockFocus.

Yet for some reason, not only does winit create NSViews on non-main threads when creating a window, but somehow we for some reason implement Send + Sync on Window!

I could swear that the glutin docs mentioned at least in one place that the window isn't always Send or Sync, but after grepping the whole source I can't figure out where. Nevertheless, this discrepancy between what should be and what is has lead to numerous people asking about it - or maybe I just bug too many people about it.

[goddessfreya]

Might not necessarily be the case, as pointed out by @mtak-. #871 (comment)

[ghost]

As of eventloop-2.0, doesn't winit ensure here that windows can only be created from the main thread?

[Osspial]

@aleksijuvani That's a good point. Also, since EventLoop is neither Send nor Sync, I'm not sure it's even possible to create a window off the EventLoop thread.

[francesca64]

Closing this, since all the magic I did with GCD (which has since been improved by others!) made this a non-issue as of EL2's release.