WindowHandle is not sound

[daxpedda]

Currently, the rwh::WindowHandle we return gets a lifetime to Window. Unfortunately this doesn't really work out because the actual lifetime of the Window isn't connected to it's semantic lifetime. If the EventLoop is exited, all Windows become invalid, therefor making all connected WindowHandles unsound to continue to use.

One simple solution that was proposed in IRC by Ralith is to extend the lifetime of all Windows even after the EventLoop was exited. This might be a viable solution as recreating the EventLoop isn't allowed anyway (except on Web).

For a more "proper" solution, we would have to introduce a lifetime to Window that is connected to the EventLoop. This would require a major API re-design.

Also discussed in:

• Make safe WindowHandle s to imilictly ref-count raw-window-handle#158
• Winit API redesign #3367

[notgull]

Would be best IMO to just keep the display handle alive when a window is alive. Feels more semantically sound. Just keep the Display handle or whatever in an Arc.

[kchibisov]

You don't have handle on macOS though, that's the issue.

[notgull]

You don't have handle on macOS though, that's the issue.

My impression for macOS though is that, when the event loop ends, the application exits, effectively preventing the Windows from being accessed. So this isn't a problem there.

[kchibisov]

I remember there were caveats around that and that's part of the reason we explicitly require drop for windows between run_on_demand iterations.

[notgull]

For the platforms I know:

• Windows doesn't really have a "display" object anyways, windows can be manipulated at any time without issue.
• macOS (and iOS AFAIK) exit the application once the event loop exits, so it shouldn't have this problem.
• X11 and Wayland keep around the connection to the server in an Arc in the window, so it shouldn't have this problem.
• The Android window is refcounted internally, I think. So there may be errors but there won't be soundness issues.
• Web is just checked indexes into a JS array, so it can't violate memory safety.
• I'm not sure what Redox does but it probably won't cause memory safety issues.

Do you have a link to this discussion? There's probably something I've missed.

[madsmtm]

macOS (and iOS AFAIK) exit the application once the event loop exits

Only iOS.

But on macOS, Window basically contains an Arc, and can safely live beyond EventLoop.

[madsmtm]

For reference: @daxpedda noted in #3367 (comment) under "Nothing Outlives the Event Loop" that one solution could be: the event loop can't be exited without dropping all Windows first, with the drawback that users to have to "track down" all Window handles to be able to exit their application.

Further discussion notes from out meeting last week in here.

Direct Window access: #3434.