So far I’ve used temporary variables to store new position and movement variables from server and used them in the update loop.
I was just wondering if there was an existing way to instead interact with Unity API directly from another thread?
If not then I was thinking of creating a class that would use queuing and cashing to allow interaction with the main thread, which would in the background happen in the main thread.
You can’t do it directly. You have do some sort of task base system or queue and caching or the like.
If you think about it, this is what you really want to do anyway. Calling code in the engine at arbitrary points would be disastrous. If you moved a transform during rendering you could get nasty visual tears. If you moved a transform during FixedUpdate you could produce physics hiccups. And so forth.
@Kiwasi Why would moving transforms during FixedUpdate have that bad effect? As far as I know it is simply a way to update in sync with physics update.
He means ‘while the engine is executing the physics update,’ I think.
Anyway, yes: right now almost none of the Unity API is thread safe (I think it’s pretty much just Debug.Log). We do have plans to make it easier to write multithreaded things in a safe way, but completely freeform API access from other threads is probably never going to happen.
The idea of setting up a ‘processing queue’ of tasks to be completed on the main thread is a good one that has been used by many projects, so you should be good to go for that.
This is what I use to deal with multi-threaded situations:
You create an instance of this class on the main thread, and call ‘Update’ during a unity Update message (you could also call it on FixedUpdate or LateUpdate… whichever).
Then on any thread you call either ‘Invoke’ or ‘BeginInvoke’ (naming convention comes from WinForms which I spent a lot of time writing, and has similar functionality for returning to the main gui pump). Invoke blocks, BeginInvoke does not.
You can always check ‘InvokeRequired’ to test if you’re on the main thread or not.
And of course, because it inherits from WaitHandle, you can just call ‘WaitOne’ to block any thread until the next time Update is called.
You shouldn’t call Invoke or WaitOne from the main thread.
Here I have it inside a Singleton I call ‘GameLoopEntry’:
Sorry, as in while the engine is doing it’s physics update. I think the best we will see on Unity’s side is simply some sort of queuing system. Basically a GameObject you can drop in the scene with a bunch of delegates that lets you queue arbitrary code back onto the main thread on the various hooks that it’s appropriate to use.
Since this is trivial to implement yourself, or to download a decent frame work, I don’t see Unity moving on it anytime soon.
I’ve posted my solution here MainThread function caller - Unity Engine - Unity Discussions
It’s a simple queuing based class that should be able to do everything you need.