“Unity doesn’t support multithreading!”
I’ve heard that many times, by many different people. Yet there are some, if you search hard enough, who refute the fact. The truth is, coming straight to you from The Keyboard of SnowHydra Games, is that you can have multiple threads in a Unity game.
However, as you may have heard, threads in Unity projects have LIMITED FUNCTIONALITY.
You pretty much cannot use any Unity functions while multithreading.
This means you will not be able to set transform.position, nor rigidbody.AddForce, nor can you even think about just changing the name of a GameObject. That doesn’t mean you’re never allowed to do those things, it just means you can’t do them in a separate thread. Unity’s functions can only be called from the “main” thread that we have access to.
That’s OK though! You could always do your asynchronous calculations on that new thread, then set your transforms or what have you to the new values once you’re done calculating it. This of course would only be useful for more complex situations–there’s no use for the majority of circumstances.
SPOOKY THREAD INCONSISTENCY
It was rather spooky, to say the least. I pushed a change to a project that separated some calculations onto a separate thread. It worked all fine and dandy on my machine, but on another team member’s, it would crash his editor. Turns out when he stopped the game in the editor, the thread I created continued spinning for eternity.
Threads in Unity can be unpredictable like this. Fortunately we fixed it by making sure the thread doesn’t continuously spin, however it’s not to say that there could be other differences of thread behavior between different operating platforms.
Anyway I think the point of this is to say “Unity’s compiler will let you program things using threads and it’ll work” and “stay safe from threads, kids.”