Provide a way to return from the event loop

[spennydl]

Currently we have #797 and #845 working on bringing in webassembly support. Unfortunately, in the browser we have to return from function calls. These backends both have to rely on throwing exceptions as control flow in order to break out of the loop.

Is there a way winit could provide some mechanisms for loops that work this way? I noticed some of the other backends implement a run_return function that is usually called by run; perhaps winit could standardize on this?

[est31]

See prior discussions on the topic: #459 (comment)

#459 (comment) explicitly says that throwing exceptions is the intended design.

[Osspial]

Throwing exceptions is indeed the intended design. It's not particularly pretty, but it's the only API I'm aware of that behaves mostly identically on all platforms.

[blm768]

Seems like a reasonable approach would be to offer both methods. Since WebAssembly initialization tends to require platform-specific tweaks anyway (i.e. for resource loading, since standard filesystem APIs aren't available), most programs targeting a wasm backend would probably go through the specialized run_return function anyway. Having a bit of "shim" code to adapt this into "run+throw" would (hopefully) take care of the programs that don't.

There is one additional concern that was mentioned briefly but may require further analysis: at least according to the wasm-bindgen docs, WebAssembly has no support for stack unwinding, which means that nothing that was constructed between the start of the entry point function and the exception that breaks out of run will be Dropped properly. I've had this issue bite me multiple times when working on my own project; with the kinds of borrowing patterns that are common in WebAssembly projects, almost anything that panics tends to leave "borrowed" RefCells that become permanently locked and unusable (although that's less likely to be an issue in this particular case). This can also affect program semantics in other, more subtle ways, which users may not have accounted for when trying to port their code to work in a wasm environment.

(Then again, since the user would be expecting run to not ever return, they're probably not relying on Drop or unwinding behavior except for final cleanup, so maybe that's a non-issue in practice, at least 99% of the time.)

[Osspial]

If we're exposing run_return on desktop platforms, I see no reason not to expose an equivalent method for WASM platforms. It should be named differently though, to prevent confusion.

[daxpedda]

This is covered by EventLoop::spawn().

Fixed by #2208.