After thinking about this more and more, I've come to realize that
forcing UnwindSafe is not the intention of the bound on catch_unwind.
This should have been evident to me by the fact that thread::spawn does
not require UnwindSafe, yet it catches panics. The key qualifier I wasn't
noticing was that the design of the trait is to prevent *easily*
observing invariant states.
Since this panic catch results in dropping and then subsequently closing
everything that was passed to it, it fits the same general shape as
thread::spawn, so I'm removing the bounds.
When I ran the new Kludgine on my mac last night, I was surprised to
discover it didn't work. It turns out create_surface needs to be called
on the main thread on Metal.
This commit adds a way to provide a callback that can be remotely called
through the EventLoopProxy. This allows Kludgine to send a
CreateSurfaceRequest to the main event loop and receive a wgpu::Surface
back.
Prior to this commit, if a window panic happened, the window would be
left on the screen frozen. Now, the panic is caught and the window is
closed before resuming the panic.
The app event loop has a separate message it receives when a window
panics, and if it's the last window, the process exits with a non-zero
exit code.
This places the burden of handling a panicking window into the
developer's hands: ultimately if the window has a way to communicate
with it, the behavior is being dropped as part of the panic handling,
which ensures any channels the window had will be dropped too.
