Application.Quit()

Hi All,
what really happens when I call "Application.Quit()"? I mean, if a Unity update process is running, is it interrupted or completed for every MonoBehaviour object?
Can "Application.Quit()" be called from a different thread or from a Timer?

Regards,
Gianni

 

When you build a project, and call Application.Quit(); it will automatically quit.

 

That's OK, but I asked more details.

 

I never tested this, but i'd imagine that Application.Quit() can only be called from the main thread, as it is part of the Unity API. Thus, since code is executed sequentially, with the exception of multithreading, the application will quit as soon as Application.Quit() is called somewhere in the program. I'd imagine this would be the same case if it was possible to be used multithreaded tho. Depends a bit on the implementation, since it may also toggle a bool or something that is checked before each update loop.
Why are you asking? Just some curiosity, or maybe a problem you need help with?

 

I'm also guessing it can only be called from the main thread. It would be fairly easy to test whether or not other Update methods are still called for that frame.

I've made a MonoBehaviour singleton before that makes calls main thread safe. It stores calls made and calls them in the next update cycle. That would also work for Application.Quit if needed.

Finally, note that there is an OnApplicationQuit in MonoBehaviour. So if you need to do something just as the application is being quit, you can do it there instead of in Update. If this action takes a while, you can even start up a new thread at this point. (As long as you don't need any main thread calls anymore.) Just make sure this thread ends at some point, so the application will actually quit.

 

There's some info in the docs about what happens.

If you look at the flowchart on the same page, it does look like the game is quit at the end of the frame when it was called, rather than immidiately.

 

Thanks Yoreki,
I have a C++ application (the Controller) and an application built with Unity (the Visual). The Controller can run the Visual and also quit the Visual. Controller and Visual communicate via Apache Thrift. The Visual runs in exclusive mode (for performance reasons). When the Controller asks the Visual to quit, then I implemented a way (I have to skip the details here) to add this event to the "update()" implementation of my Main.cs (a MonoBehaviour) so that in the next update() call Application.Quit() is executed. This works fine but in one case: Controller and Visual run on the same PC (Windows). In fact since the Visual runs in exclusive mode it is iconized as soon as the focus goes to the Controller application. When the Viewer is iconized no update() is called, so Application.Quit() is never called.

That's why I would like to know if I can call Application.Quit() from another thread or timer: to be independent on update() calls.

I need a way to quit the Unity application (the Visual) that works in every scenario, even if the Unity application is iconized.

 

Yes, I have to write some strings to a log file since Application.Quit() does not wotk inside the Unity Editor. Not such fun ... :-(

If I understood correctly, I did something similar. But since I don't want to use singletons because of code testability, I used a Command Pattern instead and append commands to process on every update to my Main MonoBehaviour-derived class. One of those command is ApplicationQuitCommand. There I call Application.Quit().

I already implemented my application cleanup in OnApplicationQuit, thanks ;-)

 

Not entirely sure about your setup, but is "run in background"(or whatever it's called) enabled?

 

Thanks for the interesting link. So, when an Application.Quit() is called, for example in a update() implementation of a MonoBehaviour, the flow goes on till End of frame then a sort of flag tells Unity to handle the Application quit and OnApplicationQuit is called for every MonoBehaviour. Then application exits. Is that right?

 

You may be right, but is "Application.runInBackground = true" compatible with FullScreenMode.ExclusiveFullScreen?

 

A multiscreen setup can have sn unfocused fullscreen window, not sure if it applies to you.