Simplify winit runner exit code reporting

[Brezak]

Objective

Returning a app exit code from the winit runner is complicated and deadlock prone.
The code to return a app exit code is rather shoddy. It's use of mutex is redundant, It uses unwrap when not required and can be broken by a maintainer simply forgetting to set a value.

Solution

Switch to using a channel.

• Deals with situations in which a event loop exits unexpectedly.
• Never panics. Even in extreme cases.

[Brezak]

The original plan was to switch to a arc containing a atomic u8. Although such a solution would use much less memory it would be rather annoying to deal with.

[BD103]

Returning an app exit code from the winit runner is complicated and deadlock prone.

Is there a specific issue for this, or do you have a reproduction? I'm curious of the cause behind this change.

[BD103]

The original plan was to switch to a arc containing a atomic u8. Although such a solution would use much less memory it would be rather annoying to deal with.

Personally, I think using atomics in this situation would not be too bad; we just use Ordering::SeqCst for everything and follow up by seeing if we can lower it to Aquire and Release.

Then again, I may be more familiar with concurrency.

[Brezak]

Returning an app exit code from the winit runner is complicated and deadlock prone.

Is there a specific issue for this, or do you have a reproduction? I'm curious of the cause behind this change.

My phrasing was rather hyperbolic, sorry. It was predicated on the possibility of the event_loop getting leaked for some reason. I've realized that this wouldn't actually deadlock but would cause a panic when the Arc::get_mut call at the end of winit_runner would fail.

The original plan was to switch to a arc containing a atomic u8. Although such a solution would use much less memory it would be rather annoying to deal with.

Personally, I think using atomics in this situation would not be too bad; we just use Ordering::SeqCst for everything and follow up by seeing if we can lower it to Aquire and Release.

Then again, I may be more familiar with concurrency.

Using a channel means we get to detect situations in which, a future maintainer working on the event loop forgets to set an exit code before exiting the event loop. Though my primary reasoning for not using atomics is that the code would be harder to parse.

On the ordering of operations. We could use Ordering::Relaxed. If nothing's gone wrong (see concerns with panic above) synchronization between sending and receiving a exit code is guaranteed by the event loop itself exiting only after a exit code was stored.

[BD103]

I'm not familiar with the event loop, so I recommend getting one more approval before merging.

Either way, your reasoning makes sense! I have a few small notes, but nothing blocking.

[alice-i-cecile]

@pietrosophya could you take a quick look at this if you have the time and interest?