CODEWITHSUNDEEP
c#multithreadingunity-game-engine
KansaiRobot
KansaiRobot

Reputation: 10012

Why is "InvokeOnAppThread" used?

(The question is following but please read the info below as well)

According to the documentation InvokeOnAppThread executes a callback item on application thread.

Browsing more into the documentation , it seems there is the "UI Thread" and the "application thread".

However the link they offered for more information on this, is not there.

So, is there by default two threads on any Unity program? Can someone explain to me about InvokeOnAppThread? Why and when it should be used?

(I have already searched and looked on pages dealing with threading in Unity. It is clear there is a UI Thread by default and it seems multithreading is not recommended since other threads are not allowed access to the UI Thread. As I understand this can be solved by using callbacks)- so I have already done research on this

The "Application thread" mentioned in the docs is not mentioned anywhere else

Just to avoid duplicates I have already searched in SO if there is already an answer to this. The search output 0 results, so it is clear to the best of my efforts this is not a duplicate question

Upvotes: 2

Views: 1244

Answers (2)

David Oliver
David Oliver

Reputation: 2321

It looks like this is the page that should be reached from the broken link.

From that page:

Now, let’s take a closer look at AppCallbacks class. When you create it, you specify that your game will run on different thread, for backward compatibility reasons you can also specify that your application can run on UI thread, but that’s not recommended, because there’s a restriction from Microsoft - if your application won’t become responsive after 5 seconds you’ll fail to pass WACK (Windows Application Certification), read more here - http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh184840(v=vs.105).aspx, imagine if your first level is pretty big, it might take significant amount of time to load it, because your application is running on UI thread, UI will be unresponsive until your level is fully loaded. That’s why it’s recommend to always run your game on different thread.

Essentially the 'UI thread' is the main thread from the point of view of the WinRT/UWP runtime. In order not to block that thread, all Unity-specific code - MonoBehaviour scripts, coroutines, etc - runs on a separate thread, the 'application thread,' which is the main thread from the point of view of the Unity engine.

You would use InvokeOnUIThread if you were on Unity's main thread and you wanted to do something on the Windows UI thread (eg, create a native pop-up). You'd call InvokeOnAppThread if you were on the UI thread and wanted to marshal back to the Unity main thread (eg, start a coroutine, instantiate a GameObject).

Upvotes: 2

saarp
saarp

Reputation: 1951

I'm not familiar with Unity, but this is a typical requirement with WinForms development in whatever framework you are using.

You can find detailed description of the issue in the Control.InvokeRequired property documentation and also in this MSDN page.

What the explanations say is that events for a control should only be handled by the thread that created them because otherwise they are not thread safe. This is a little different than the guidance I have understood in the past - your main UI thread is just listening for events and handing them off to a ThreadPool for processing so that user responsiveness (ie. responding to mouse/keyboard events) never halts because the app is doing something.

The Control.InvokeRequired check is supposed to tell you if you are on the UI thread so that you can queue another event that should execute on a different thread so the main UI handling thread does not block. The implementation details may have changed somewhat since I last worked with this, though.

Upvotes: 0

Related Questions