Safe Cross-Platform Off-Thread Rendering

[daxpedda]

The goal of this proposal is to make it Rust safe for users to render on a different thread then the window with the same API cross-platform.

Blockers are:

• Windows: handle is not !Send and is unable to be created safely on a different thread.
• Web: due to JS limitations a surface can only be created on a different thread and can never be sent to one.
• MacOS/iOS: the surface has to be created on the same thread as the window (i.e. the main thread).

To make this truly cross-platform, Web is the limiting factor: not being able to send the surface to a different thread.
To address this we:

• Windows: Making Windows Send + Sync #196.
• MacOS/iOS: patch consumers to use libdispatch to create the surface on a different thread.

[notgull]

I think macOS/iOS make this impossible, right? Since all rendering to those windows must take place on the main thread.

For Windows, when you create the DC it has to be on the same thread as the window handle. DX11 is different.

[madsmtm]

macOS/iOS: You can only touch NSView/NSWindow/UIView/... from the main thread, but CALayer is thread-safe (at least it isn't main-thread bound).

So if you want to render on a separate thread, you can either:

• Create softbuffer::Surface (internally CALayer) from NSView/UIView on the main thread, and send that to a separate thread.
• Or send Window to another other thread, call Surface::new, internally use libdispatch to block and access the NSView/UIView to create the CALayer on the main thread, and then use the new CALayer on the separate thread.

The first option is ideal, the second option is doable if nothing else.

What you ideally want to avoid is keeping the winit::Window around on the separate thread, since every operation on it (including Drop) requires blocking, waiting for the main thread to do the action.

[madsmtm]

(At least I think that's how it is, but Apple's APIs are a bit under-documented, it might be that e.g. Surface::resize would only be safe if synchronized with the main thread?)

[madsmtm]

Yeah, inspecting this official sample code seems to suggest that you can use CALayer as long as you synchronize resizes (which softbuffer probably could do internally).

[daxpedda]

For Windows, when you create the DC it has to be on the same thread as the window handle. DX11 is different.

Actually ReleaseDC just has to be called from the same thread as GetDC, but GetDC can be called from any thread. The DC itself is !Send + !Sync and access has to be synchronized. (Guess you could implement Sync if all your methods are &mut)

I've read up on all the previous discussions on why HWND is considered !Send and I see where these arguments are coming from. The idea is that because HWND is not always Send, it should be considered !Send. However, I think this argument is flawed. HWND is officially a *const (), but it will never be de-referenced by users. The reason why pointers are !Send is because they do not provide the safety guarantees of Send (see the Rustonomicon and RFC 738). Its not because they are unsafe to de-reference on another thread, they are unsafe to de-reference anywhere!

HWND is just a handle and in fact it does provide the safety guarantees of Send:

Types that can be transferred across thread boundaries.

The fact that some APIs have to observe HWNDs thread-affinity does not make HWND !Send, it makes them unsafe.

I believe that this conclusion has been mirrored before in #85 (comment), from somebody clearly understanding Windows much better then I do.

Another argument that was brought up is that users who really need this can build a safe instruction around this themselves. This is always true, but in this case we have a good use-case ourselves: allowing safe cross-platform off-thread rendering by the user, which is currently not possible specifically because of this limitation.

[Lokathor]

HWND is only !Send if pointers are !Send.

And pointers could be Send, but the standard library chose to make them !Send "as a lint".

So, I think we should make HWND also be !Send "as a lint".

Remember that end users can always just override our decision if they "know what they're doing". You can always just stick a Send wrapper around any type and Rust will accept it. This isn't Copy we're talking about.

[notgull]

I've read up on all the previous discussions on why HWND is considered !Send and I see where these arguments are coming from. The idea is that because HWND is not always Send, it should be considered !Send.

It is always !Send. If you drop an HWND on another thread, it will lead to undefined behavior. For a similar reason, MutexGuard in the standard library is !Send but Sync.

HWND can be used from other threads, but not dropped on other threads. Hence, !Send and Sync.

[daxpedda]

HWND is only !Send if pointers are !Send.

And pointers could be Send, but the standard library chose to make them !Send "as a lint".

So, I think we should make HWND also be !Send "as a lint".

Remember that end users can always just override our decision if they "know what they're doing". You can always just stick a Send wrapper around any type and Rust will accept it. This isn't Copy we're talking about.

Ofc end users can just override it. But the goal of this whole issue is to make it safe and cross-platform. If users have to override it by using a cfg, its not cross-platform. If users have to override it by using unsafe, its not safe.

This is also not simply about making Win32WindowHandle Send, its about changing the safety contract. Right now consumers can expect Win32WindowHandle to observe thread affinity because its !Send, if end-users explicitly work around that, consumers can't expect this anymore.

This proposal changes the safety contract by requiring consumers to figure out themselves if the passed HWND is safe to use in their scenario. We could in theory make all of this still work with !Send e.g. by allowing Winit to produce a Win32WindowHandle in another thread, even if the handle is !Send, but now !Send provides no value at all. In fact I would argue it would be harmful because consumers might consider not fully enforcing the safety contract because circumventing !Send already requires unsafe.

I've read up on all the previous discussions on why HWND is considered !Send and I see where these arguments are coming from. The idea is that because HWND is not always Send, it should be considered !Send.

It is always !Send. If you drop an HWND on another thread, it will lead to undefined behavior. For a similar reason, MutexGuard in the standard library is !Send but Sync.

HWND can be used from other threads, but not dropped on other threads. Hence, !Send and Sync.

I believe that you are confusing HWND with the actual window. HWND is just an integer and has no Drop semantics. It is very much Send not just because its just an integer, there are many APIs that can be used from any thread with a given HWND, ergo not having to observe thread affinity. In this case we are talking specifically about CreateSwapChainForHwnd. In fact HWND goes beyond that and it is even possible to pass it across process boundaries.

But the window itself is indeed !Send + Sync and trying to destroy it from another thread would be unsound.

[Lokathor]

Safety only make sense in the context of a group of operations. Vec::set_len would be safe on it's own if that were the only method the type had, but it's not. You're saying that people could safely do this or that by calling different foreign functions, but all of those are unsafe, so someone other than this crate would already be writing a huge unsafe wrapping system, and making more informed decisions than we can.

[daxpedda]

RWH types are independent of producers and consumers. I'm proposing to change the safety contract to allow for a specific use-case, as in the title. This part can only be done here, in RWH.

Lets go down specifically into what motivates this discussion in the first place: Winit exposes RWH handles to the user, which the user then passes on to Softbuffer or Wgpu. If we want to allow safe cross-platform off-thread rendering, the safety contract of the handle has to change so that consumers need to check for thread-affinity themselves.

Ergo Softbuffer and Wgpu don't need to change anything in this case. But consumers who deal with the window directly (I don't want to name examples without knowing which APIs specifically would be unsound) would suddenly become unsound. So without changing the safety contract, interactions that were safe until now would suddenly become unsound if Winit starts exposing Win32WindowHandle safely off-thread.

We could change the safety contract without implementing Send. But as mentioned before: the specific change to the safety contract proposed here would eliminate any advantage of !Send.

I would be very interested in any alternative proposal to address this issue. But I don't know how this could be solved outside of RWH.

@Lokathor I couldn't find you in our Matrix channel, but we have an upcoming meeting where this will be discussed. If you want to join give us a ping there. Your opinion would be greatly appreciated!

[Lokathor]

I don't believe I have time for a meeting, but I guess for me it comes down to this: we're a conveyer of data, that's it. In my view, we don't really have a safety contract of our own, we're just giving a particular name to particular values so that rust lets people transfer the value from place to place.