Winit: EventLoop run terminates entire application when finished

[GideonUng]

I just had a look at glutin 0.22.0-alpha3 (upgraded from 21) and i saw that the EventsLoop poll_events is gone and now there is only the EventLoop run.
In its description it said that everything should be moved into its callback since they wont be droped and that was a bit weird and then i looked into the x11 implementation and found this:

self.run_return(callback);
::std::process::exit(0);

Who in their right mind thinks this is a good idea???
why does a library i use fucking terminate my entire application??
Who wakes up one morning and says hey i should add leaking resources by default into the core of this windowing library?

[goddessfreya]

Who in their right mind thinks this is a good idea???
why does a library i use fucking terminate my entire application??
Who wakes up one morning and says hey i should add leaking resources by default into the core of this windowing library?

Lets please adhear to the rust community code of conduct:

Please be kind and courteous. There’s no need to be mean or rude.
Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

---

We also expose run_return, and it comes with it's caveats: https://docs.rs/winit/0.20.0-alpha3/winit/platform/desktop/trait.EventLoopExtDesktop.html#caveats It should be noted, this function cannot be implemented on web/ios/android.

[Osspial]

The short of the rationale is that, like @ZeGentzy mentioned, it's the only cleanish way to make the run method work on all platforms we support. I'll fully admit that I'm not very happy with having to use std::process::exit to accomplish that, but I'm unaware of a better way of doing it.

If you've got ideas about how to work around that without breaking cross-platform compatibility, please bring them up! We'll happily merge a solution that gets the job done in a cleaner way, if one exists.