I currently have a code which retrieves data from a database and visualizes it in unity3D. However, everytime it retrieves data in the FixedUpdate() function, it spikes dramatically every 1 second. I'm thinking about using threading to do this but i'm not sure what i'm doing wrong.
This is the Function i call in the thread.
public void retrievefromDB(){
if (timeStep - prevTimeStep > 99) {
timeStep -= 1; //special for this dataset
query = "SELECT * FROM GridData2 WHERE timestep=" + timeStep;
if (showParent)
query += " AND (Level != 10)";
else
query += " AND (Level == 10)";
query += " AND temperature >= " + minTemp + " AND temperature <= " + maxTemp;
dt.Rows.Clear ();
dt = sqlDB.ExecuteQuery (query);
prevTimeStep = timeStep;
}
}
This code lags the scene every 1 second therefore i tried to put it into a thread.
void FixedUpdate()
{
Thread testthread = new Thread(new ThreadStart(retrievefromDB));
testthread.Start ();
}
After putting it in a thread, it keeps crashing the scene after awhile.
Can anyone tell me what I did wrongly? And how do i solve it?
The cause of your original issue is relatively obvious: database access is slow. If you put a database call inline in the FixedUpdate method, you're going to essentially pause your game's movement while the DB access happens (which may well take a second if you have to initialise a connection, for example).
The main issue with your threaded code as posted is that you are starting a new thread every time FixedUpdate is called. That means you're starting 60 new threads per second (by default) which will very quickly cripple your game!
While it's fine to use C# threads in Unity for this sort of work, a better approach would be to create a single thread and allow that to manage the timing, rather than creating a new thread each time the job runs. That would mean creating the thread in Awake() or Start() instead, and then using Thread.Sleep or similar to handle the timing.
Coroutines (as suggested by Mihai in his answer) are great for fixing the timing of events, but they still run on the game thread: if you put your DB code in a coroutine, you'll still see pauses when it runs. If you must run this DB access every second, you need it in a proper thread.
That said, have you considered that the DB access might be unnecessary? A more performant model might be to cache all of the data up front and use it from memory when you need it. (This might not be possible if the data is very dynamic, or if you're running in a memory-restricted environment like a mobile device...)
Whatever you do, you need to stop accessing your database every frame.
You only need the result only once every 60 or frames. You can do this easily by using a variable in which you add up the time passed since last call.
As for multi-threading in Unity, you have three options:
A multi-threading framework for Unity, like
https://www.assetstore.unity3d.com/en/#!/content/7285
C# built-in threading
You need to be careful not to call Unity specific API from the secondary threads you spawn. It's OK to send over data structures like Vector3, Color, etc., but don't call reference objects like GameObjects or Components.
https://msdn.microsoft.com/en-us/library/dd321439%28v=vs.110%29.aspx
Unity Coroutines
Coroutines are Unity's way of simulating multiple threads. It's quite a powerful tool for getting things to run asynchronously in the same thread
http://docs.unity3d.com/Manual/Coroutines.html
using System.Threading.Tasks;
public class Example
{
void StartOnDifferentThread()
{
Task.Factory
.StartNew(() =>
{
FunctionToRun();
})
.ContinueWith(task =>
{
if (task.IsCompleted)
{
// handle result
}
else if (task.IsFaulted)
{
// handle error
}
});
}
void FunctionToRun()
{
// do stuff
}
}
It finally works now. Just had to add these in retrievefromDB()
public void retrievefromDB(){
while(true){
if (timeStep - prevTimeStep > 99) {
timeStep -= 1; //special for this dataset
query = "SELECT * FROM GridData2 WHERE timestep=" + timeStep;
if (showParent)
query += " AND (Level != 10)";
else
query += " AND (Level == 10)";
query += " AND temperature >= " + minTemp + " AND temperature <= " + maxTemp;
dt.Rows.Clear ();
dt = sqlDB.ExecuteQuery (query);
prevTimeStep = timeStep;
}
Thread.Sleep(1);
}
}
And put this into the Start() function
testThread = UnityThreadHelper.CreateThread (() =>
{
UnityThreadHelper.TaskDistributor.Dispatch (() => retrievefromDB ());
});
testThread.Start ();
I'm using the threadhelper from
http://forum.unity3d.com/threads/unity-threading-helper.90128/
so u can go and check it out.
Thanks to everyone who helped! :)
Related
My problem is I try to use Unity socket to implement something. Each time, when I get a new message I need to update it to the updattext (it is a Unity Text). However, When I do the following code, the void update does not calling every time.
The reason for I do not include updatetext.GetComponent<Text>().text = "From server: "+tempMesg;in the void getInformation is this function is in the thread, when I include that in getInformation() it will come with an error:
getcomponentfastpath can only be called from the main thread
I think the problem is I don't know how to run the main thread and the child thread in C# together? Or there maybe other problems.
Here is my code:
using UnityEngine;
using System.Collections;
using System;
using System.Net.Sockets;
using System.Text;
using System.Threading;
using UnityEngine.UI;
public class Client : MonoBehaviour {
System.Net.Sockets.TcpClient clientSocket = new System.Net.Sockets.TcpClient();
private Thread oThread;
// for UI update
public GameObject updatetext;
String tempMesg = "Waiting...";
// Use this for initialization
void Start () {
updatetext.GetComponent<Text>().text = "Waiting...";
clientSocket.Connect("10.132.198.29", 8888);
oThread = new Thread (new ThreadStart (getInformation));
oThread.Start ();
Debug.Log ("Running the client");
}
// Update is called once per frame
void Update () {
updatetext.GetComponent<Text>().text = "From server: "+tempMesg;
Debug.Log (tempMesg);
}
void getInformation(){
while (true) {
try {
NetworkStream networkStream = clientSocket.GetStream ();
byte[] bytesFrom = new byte[10025];
networkStream.Read (bytesFrom, 0, (int)bytesFrom.Length);
string dataFromClient = System.Text.Encoding.ASCII.GetString (bytesFrom);
dataFromClient = dataFromClient.Substring (0, dataFromClient.IndexOf ("$"));
Debug.Log (" >> Data from Server - " + dataFromClient);
tempMesg = dataFromClient;
string serverResponse = "Last Message from Server" + dataFromClient;
Byte[] sendBytes = Encoding.ASCII.GetBytes (serverResponse);
networkStream.Write (sendBytes, 0, sendBytes.Length);
networkStream.Flush ();
Debug.Log (" >> " + serverResponse);
} catch (Exception ex) {
Debug.Log ("Exception error:" + ex.ToString ());
oThread.Abort ();
oThread.Join ();
}
// Thread.Sleep (500);
}
}
}
Unity is not Thread safe, so they decided to make it impossible to call their API from another Thread by adding a mechanism to throw an exception when its API is used from another Thread.
This question has been asked so many times, but there have been no proper solution/answer to any of them. The answers are usually "use a plugin" or do something not thread-safe. Hopefully, this will be the last one.
The solution you will usually see on Stackoverflow or Unity's forum website is to simply use a boolean variable to let the main thread know that you need to execute code in the main Thread. This is not right as it is not thread-safe and does not give you control to provide which function to call. What if you have multiple Threads that need to notify the main thread?
Another solution you will see is to use a coroutine instead of a Thread. This does not work. Using coroutine for sockets will not change anything. You will still end up with your freezing problems. You must stick with your Thread code or use Async.
One of the proper ways to do this is to create a collection such as List. When you need something to be executed in the main Thread, call a function that stores the code to execute in an Action. Copy that List of Action to a local List of Action then execute the code from the local Action in that List then clear that List. This prevents other Threads from having to wait for it to finish executing.
You also need to add a volatile boolean to notify the Update function that there is code waiting in the List to be executed. When copying the List to a local List, that should be wrapped around the lock keyword to prevent another Thread from writing to it.
A script that performs what I mentioned above:
UnityThread Script:
#define ENABLE_UPDATE_FUNCTION_CALLBACK
#define ENABLE_LATEUPDATE_FUNCTION_CALLBACK
#define ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK
using System;
using System.Collections;
using UnityEngine;
using System.Collections.Generic;
public class UnityThread : MonoBehaviour
{
//our (singleton) instance
private static UnityThread instance = null;
////////////////////////////////////////////////UPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueUpdateFunc then executed from there
private static List<System.Action> actionQueuesUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesUpdateFunc to be executed
List<System.Action> actionCopiedQueueUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteUpdateFunc = true;
////////////////////////////////////////////////LATEUPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueLateUpdateFunc then executed from there
private static List<System.Action> actionQueuesLateUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesLateUpdateFunc to be executed
List<System.Action> actionCopiedQueueLateUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteLateUpdateFunc = true;
////////////////////////////////////////////////FIXEDUPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueFixedUpdateFunc then executed from there
private static List<System.Action> actionQueuesFixedUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesFixedUpdateFunc to be executed
List<System.Action> actionCopiedQueueFixedUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteFixedUpdateFunc = true;
//Used to initialize UnityThread. Call once before any function here
public static void initUnityThread(bool visible = false)
{
if (instance != null)
{
return;
}
if (Application.isPlaying)
{
// add an invisible game object to the scene
GameObject obj = new GameObject("MainThreadExecuter");
if (!visible)
{
obj.hideFlags = HideFlags.HideAndDontSave;
}
DontDestroyOnLoad(obj);
instance = obj.AddComponent<UnityThread>();
}
}
public void Awake()
{
DontDestroyOnLoad(gameObject);
}
//////////////////////////////////////////////COROUTINE IMPL//////////////////////////////////////////////////////
#if (ENABLE_UPDATE_FUNCTION_CALLBACK)
public static void executeCoroutine(IEnumerator action)
{
if (instance != null)
{
executeInUpdate(() => instance.StartCoroutine(action));
}
}
////////////////////////////////////////////UPDATE IMPL////////////////////////////////////////////////////
public static void executeInUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesUpdateFunc)
{
actionQueuesUpdateFunc.Add(action);
noActionQueueToExecuteUpdateFunc = false;
}
}
public void Update()
{
if (noActionQueueToExecuteUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueUpdateFunc queue
actionCopiedQueueUpdateFunc.Clear();
lock (actionQueuesUpdateFunc)
{
//Copy actionQueuesUpdateFunc to the actionCopiedQueueUpdateFunc variable
actionCopiedQueueUpdateFunc.AddRange(actionQueuesUpdateFunc);
//Now clear the actionQueuesUpdateFunc since we've done copying it
actionQueuesUpdateFunc.Clear();
noActionQueueToExecuteUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueUpdateFunc
for (int i = 0; i < actionCopiedQueueUpdateFunc.Count; i++)
{
actionCopiedQueueUpdateFunc[i].Invoke();
}
}
#endif
////////////////////////////////////////////LATEUPDATE IMPL////////////////////////////////////////////////////
#if (ENABLE_LATEUPDATE_FUNCTION_CALLBACK)
public static void executeInLateUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesLateUpdateFunc)
{
actionQueuesLateUpdateFunc.Add(action);
noActionQueueToExecuteLateUpdateFunc = false;
}
}
public void LateUpdate()
{
if (noActionQueueToExecuteLateUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueLateUpdateFunc queue
actionCopiedQueueLateUpdateFunc.Clear();
lock (actionQueuesLateUpdateFunc)
{
//Copy actionQueuesLateUpdateFunc to the actionCopiedQueueLateUpdateFunc variable
actionCopiedQueueLateUpdateFunc.AddRange(actionQueuesLateUpdateFunc);
//Now clear the actionQueuesLateUpdateFunc since we've done copying it
actionQueuesLateUpdateFunc.Clear();
noActionQueueToExecuteLateUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueLateUpdateFunc
for (int i = 0; i < actionCopiedQueueLateUpdateFunc.Count; i++)
{
actionCopiedQueueLateUpdateFunc[i].Invoke();
}
}
#endif
////////////////////////////////////////////FIXEDUPDATE IMPL//////////////////////////////////////////////////
#if (ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK)
public static void executeInFixedUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesFixedUpdateFunc)
{
actionQueuesFixedUpdateFunc.Add(action);
noActionQueueToExecuteFixedUpdateFunc = false;
}
}
public void FixedUpdate()
{
if (noActionQueueToExecuteFixedUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueFixedUpdateFunc queue
actionCopiedQueueFixedUpdateFunc.Clear();
lock (actionQueuesFixedUpdateFunc)
{
//Copy actionQueuesFixedUpdateFunc to the actionCopiedQueueFixedUpdateFunc variable
actionCopiedQueueFixedUpdateFunc.AddRange(actionQueuesFixedUpdateFunc);
//Now clear the actionQueuesFixedUpdateFunc since we've done copying it
actionQueuesFixedUpdateFunc.Clear();
noActionQueueToExecuteFixedUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueFixedUpdateFunc
for (int i = 0; i < actionCopiedQueueFixedUpdateFunc.Count; i++)
{
actionCopiedQueueFixedUpdateFunc[i].Invoke();
}
}
#endif
public void OnDisable()
{
if (instance == this)
{
instance = null;
}
}
}
USAGE:
This implementation allows you to call functions in the 3 most used Unity functions: Update, LateUpdate and FixedUpdate functions. This also allows you call run a coroutine function in the main Thread. It can be extended to be able to call functions in other Unity callback functions such as OnPreRender and OnPostRender.
1.First, initialize it from the Awake() function.
void Awake()
{
UnityThread.initUnityThread();
}
2.To execute a code in the main Thread from another Thread:
UnityThread.executeInUpdate(() =>
{
transform.Rotate(new Vector3(0f, 90f, 0f));
});
This will rotate the current Object the scipt is attached to, to 90 deg. You can now use Unity API(transform.Rotate) in another Thread.
3.To call a function in the main Thread from another Thread:
Action rot = Rotate;
UnityThread.executeInUpdate(rot);
void Rotate()
{
transform.Rotate(new Vector3(0f, 90f, 0f));
}
The #2 and #3 samples executes in the Update function.
4.To execute a code in the LateUpdate function from another Thread:
Example of this is a camera tracking code.
UnityThread.executeInLateUpdate(()=>
{
//Your code camera moving code
});
5.To execute a code in the FixedUpdate function from another Thread:
Example of this when doing physics stuff such as adding force to Rigidbody.
UnityThread.executeInFixedUpdate(()=>
{
//Your code physics code
});
6.To Start a coroutine function in the main Thread from another Thread:
UnityThread.executeCoroutine(myCoroutine());
IEnumerator myCoroutine()
{
Debug.Log("Hello");
yield return new WaitForSeconds(2f);
Debug.Log("Test");
}
Finally, if you don't need to execute anything in the LateUpdate and FixedUpdate functions, you should comment both lines of this code below:
//#define ENABLE_LATEUPDATE_FUNCTION_CALLBACK
//#define ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK
This will increase performance.
I have been using this solution to this problem. Create a script with this code and attach it to a Game Object:
using System;
using System.Collections.Generic;
using System.Collections.Concurrent;
using UnityEngine;
public class ExecuteOnMainThread : MonoBehaviour {
public static readonly ConcurrentQueue<Action> RunOnMainThread = new ConcurrentQueue<Action>();
void Update()
{
if(!RunOnMainThread.IsEmpty)
{
while(RunOnMainThread.TryDequeue(out var action))
{
action?.Invoke();
}
}
}
}
Then when you need to call something on the main thread and access the Unity API from any other function in your application:
ExecuteOnMainThread.RunOnMainThread.Enqueue(() => {
// Code here will be called in the main thread...
});
Much of the writing about threads in Unity is incorrect.
How so?
Unity is, of course, totally frame-based.
When you work in a frame-based system, threading issues are completely different.
Threading issues on a frame-based system are completely different. (In fact, often much easier to deal with.)
Let's say you have a Unity thermometer display that shows some value
Thermo.cs
So it will have a function which is called in Update, like
func void ShowThermoValue(float fraction) {
display code to show the current thermometer value
}
Recall that the "Update" function in Unity simply means "run this once each frame".
That only runs once per frame, and that's that.
(Naturally, it runs only on the "main thread". There's nothing else in Unity! There's just ... "the Unity thread"!)
Somewhere else, perhaps in "IncomingData.cs", you will have a function which handles the concept "a new value has arrived":
[MonoPInvokeCallback(typeof(ipDel))]
public static void NewValueArrives(float f) {
... ???
}
Note that, of course, that is a class function! What else can it be?
You can't "reach in to" a normal Unity function. (Such as ShowThermoValue.) That would be meaningless - it's just a function which runs once each frame.Footnote 1
Let's say: values arrive very frequently and irregularly.
Image you have some sort of scientific devices (perhaps IR thermometers) connected connected to a rack of PCs
Those electronic devices deliver new "temperature" values very often. Let's say dozens of times per frame.
So, "NewValueArrives" is being called 100s of times a second.
So what do you do with the values?
It could not be simpler.
From the arriving-values thread, all you do is ................. wait for it ............. set a variable in the component!!
WTF? All you do is set a variable? That's it? How can it be that simple?
This is one of those unusual situations:
Much of the writing on threads in Unity is, simply, completely hopeless.
Surprisingly, the actual approach is extremely simple.
It's so simple you may think you are doing something wrong!!
So have the variable ...
[System.Nonserialized] public float latestValue;
Set it from the "arriving thread" ...
[MonoPInvokeCallback(typeof(ipDel))]
public static void NewValueArrives(float f) {
ThisScript.runningInstance.latestValue = f; // done
}
Honestly that's it.
Essentially, to be the world's greatest expert at "threading in Unity" - which is, obviously, frame-based - there's nothing more to do than the above.
And whenever ShowThermoValue is called each frame ...................... simply display that value!
Really, that's it!
[System.Nonserialized] public float latestValue;
func void ShowThermoValue() { // note NO arguments here!
display code, draws a thermometer
thermo height = latestValue
}
You're simply displaying the "latest" value.
latestValue may have been set once, twice, ten times, or a hundred times that frame ............ but, you simply display whatever is the value when ShowThermoValue runs that frame!
What else could you display?
The thermometer is updating at 60fps on-screen so you display the latest value. Footnote 2
It's actually that easy. It's just that easy. Surprising but true.
#(Critical aside - don't forget that vector3, etc, are NOT Atomic in Unity/C#)
As user #dymanoid has pointed out (read the important discussion below) it's critical to remember that while float is atomic in the Unity/C# milieu, anything else (say, Vector3 etc) IS NOT ATOMIC. Typically (as in the example here) you only pass floats around from calculations from, say, native plugins, thermometers etc. But it's essential to be aware that vectors and so on are NOT atomic.
Sometimes experienced threading programmers get in a knot with a frame-based system, because: in a frame based system most of the problems caused by racetrack and locking issues ... do not exist conceptually.
In a frame-based system, any game items should simply be displaying or behaving based on some "current value," which is set somewhere. If you have info arriving from other threads, just set those values - you're done.
You can not meaningfully "talk to the main thread" in Unity because that main thread ............. is frame-based!
Most locking, blocking and racetrack issues are non-existent in the frame-based paradigm because: if you set latestValue ten times, a million times, a billion times, in one particular frame .. what can you do? .. you can only display one value during that frame!
Think of an old-fashioned plastic film. You literally just have ...... a frame, and that's it. If you set latestValue a trillion times in one particular frame, ShowThermoValue will simply display (for that 60th of a second) the one value it grabs when it is run.
All you do is: leave information somewhere, which, the frame-paradigm system will utilize during that frame if it wants to.
That's it in a nutshell.
Thus, most "threading issues" disappear in Unity.
All you can do from
other calculation threads or
from plugin threads,
is just "drop-off values" which the game may use.
That's it!
Let's consider the question title...
How do you "... call a function in the main Thread"
This is completely meaningless. The "functions" in Unity are simply functions which the frame engine runs once per frame.
You can't "call" anything in Unity. The frame engine runs a number of things (many things) once per frame.
Note that indeed threads are totally irrelevant. If Unity ran with a billion threads, or with quantum computing, it would have no bearing on anything.
You can't "call a function" in a frame-based system.
Fortunately, the approach to take is dead simple, you just set values, which the frame-based functions can look at when they want! It's really that easy.
Footnotes
1 How could you? As a thought experiment, forget about the issue that you're on a different thread. ShowThermoValue is run once a frame by the frame engine. You can't "call" it in any meaningful way. Unlike in normal OO software, you cannot, say, instantiate an instance of the class (a Component?? meaningless) and run that function - that is completely meaningless.
In "normal" threaded programming, threads can talk back and fore and so on, and in doing so you have concerns about locking, racetrack and so on. But that is all meaningless in an ECS, frame-based, system. There is nothing to "talk to".
Let's say that Unity was in fact multithreaded!!!! So the Unity guys have all of the engine running in a multithreaded manner. It wouldn't make any difference - you can not get "in to" ShowThermoValue in any meaningful way! It's a Component which the frame engine runs once a frame and that's that.
So NewValueArrives is not anywhere - it's a class function!
Let's answer the question in the headline:
"Use Unity API from another Thread or call a function in the main Thread?"
The concept is >> completely meaningless <<. Unity (like all game engines) is frame-based. There's no concept of "calling" a function on the main thread. To make an analogy: it would be like a cinematographer in the celluloid-film era asking how to "move" something actually on one of the frames.
Of course that is meaningless. All you can do is change something for the next photo, the next frame.
2 I refer to the "arriving-values thread" ... in fact! NewValueArrives may, or may not, run on the main thread!!!! It may run on the thread of the plugin, or on some other thread! It may actually be completely single-threaded by the time you deal with the NewValueArrives call! It just doesn't matter! What you do, and all you can do, in a frame-based paradigm, is, "leave laying around" information which Components such as ShowThermoValue, may use, as, they see fit.
Another solution to run code on the main thread, but without requiring a game object and MonoBehavior, is to use SynchronizationContext:
// On main thread, during initialization:
var syncContext = System.Threading.SynchronizationContext.Current;
// On your worker thread
syncContext.Post(_ =>
{
// This code here will run on the main thread
Debug.Log("Hello from main thread!");
}, null);
Use UniRx's multithreading pattern, UniTask and RxSocket together.
[SerializeField] private Text m_Text;
async UniTaskVoid Connect() {
IPEndPoint endPoint = new IPEndPoint(IPAddress.IPv6Loopback, 12345);
// Create a socket client by connecting to the server at the IPEndPoint.
// See the UniRx Async tooling to use await
IRxSocketClient client = await endPoint.ConnectRxSocketClientAsync();
client.ReceiveObservable
.ToStrings()
.ObserveOnMainThread()
.Subscribe(onNext: message =>
{
m_Text.text = message;
}).AddTo(this);
// Send a message to the server.
client.Send("Hello!".ToByteArray());
}
I'm trying to run a script that will generate a "ramps" upon touch between point a and b. This code receives a list of where the elements of the ramps should be and then instanciates and places them on the screen.
However the coroutine is only running once and I can't understand why. Can anyone give me some advice?
Thank you very much in advance
public IEnumerator CreateRamp(List<Vector3> lP, float angle)
{
int i = 1;
while (i <= lP.Count)
{
Debug.Log("Iteration " + i + " of " + lP.Count + " position is " + lP[i]);
GameObject item = Instantiate(Resources.Load("floor")) as GameObject;
item.transform.position = current_Position;
item.transform.eulerAngles = new Vector3(0, 0, UnityEngine.Random.Range(0f, 360f));
item.GetComponent<Ramp>().strtPos = item.transform.position;
item.GetComponent<Ramp>().strtRot = item.transform.eulerAngles;
item.GetComponent<Ramp>().strtScale = new Vector3(0.4f, 0.4f, 1);
item.GetComponent<Ramp>().tgtRot = new Vector3(0, 0, angle);
item.GetComponent<Ramp>().tgtPos = lP[i-1];
i += 1;
yield return new WaitForSeconds(0.2f);
}
}
I suspect your condition i <= lP.Count is true only once. (Maybe lP.Count == 1, I think).
The way co-routine works is that, the code inside the CreateRamp function is executed across multiple frames.
When you StartCoroutine(CreateRamp(...)), it is immediately run until it hits yield statement. It will wait there for 0.2 seconds and will be run again from the statement right after the yield.
In the second execution, it evaluates the condition i <= lP.Count again and see that it is False => it jumps out of the loop and because it hits the end of the function, that co-routine will be stopped, no more execution in the future.
Since this function is an IEnumerable it should be treated by other code as a list of Ramp objects. I suspect (there isn't enough of your code to know), that the way you are calling this function is incorrect.
On a side note, with your yield returning a waitforX, It would be better in the long term to either perform the wait outside of this function (where you are calling it from) or at the very least add the wait period as a parameter to the function. Hard coded values like that will end up biting you later on, especially if your game's code-base grows. I recommend it be exposed as a setting on your GameObject, so it can be tweaked from the editor.
One other thing, How do you destroy these Ramp objects when you are done with them? It might be good to consider storing references to them as you create them so you can destroy them later.
I am writing a game with some logic that records player actions and then replays them in the same sequence at the same timing but with other influences involved at a later date.
So far I have the code sort of working, it records perfectly as I require it, and then plays back the sequence perfectly, but the issue has been timing.
As an simple example. If the character is to walk from A -> B -> C but to wait for x time at B, then the code easily traverses the path, but will not stop at B for the given time.
So I wrote a couple of functions that I thought might handle this as you can see here.
private IEnumerator followSequence()
{
// Loop through each action steps in sequence.
foreach (Action step in sequence)
{
//Check if the action time is less than the current clock time.
Debug.Log("Step.tick: " + step.tick + " || Clock.tick: " + clock.getTick());
if (clock.getTick() < step.tick)
{
//If so wait out the difference to resync the action.
yield return new WaitForSeconds(step.tick - clock.getTick());
}
// Carry out the step.
play(step);
}
yield break;
}
private void play(Action step)
{
Debug.Log(step.type);
// Set up a followpath script
FollowPath follow = (player.GetComponent<FollowPath>() ? player.GetComponent<FollowPath>() : player.AddComponent<FollowPath>());
// Tell the follow path script that object is not a guard.
follow.isGuard = false;
// Create a new point object on the map
Transform aPoint = (Transform)Instantiate(PathPoint, step.point, Quaternion.identity);
path.points.Add(aPoint);
// Initiate movement.
follow.Path = path;
follow.TravelPath();
// Check if action is an objective.
if (step.type == Action.Type.Action)
{
step.actions.OnClick();
}
}
Now if I comment out the *yield return new WaitForSeconds()* part in the first function, the code works as expected and completes the step in the sequence just not to the given timing.
When the same code is not commented out, then the timings work perfectly and the 2nd *Debug.log("step.type")* is called at the exact right time, however the character no longer moves, I.E. the *follow.TravelPath()* never seems to be executed.
I have tried making the 2nd function an IEnmerator and yielding to it. I have tried a custom wait() function. I have tried yielding to the TravelPath() function.
Has anyone any more ideas I have follow up or where I could look to try and resolve this?
Edit:
Code that calls followSequence() as requested:
private void playActions()
{
// Reset player immediately to the starting position
player.transform.position = sequence[0].point;
// Stop the character and freeze the scene when alarm sounds!.
player.GetComponent<IncrementController>().freeze();
player.GetComponent<IncrementController>().enabled = false;
// Restart the clock and scene.
clock.Restart();
sceneManager.restart();
// Activate guard and remove sphere.
guard.SetActive(true);
guardShere.SetActive(false);
// Stop recording;
recording = false;
line.SetActive(false);
// Start playback sequence.
StartCoroutine(followSequence());
}
The behavior is as expected, on the line there you do yield return the execution of the context is paused until you do MoveNext() (which does apparently never happen) on the enumerator, which is returned by followSequence.
But as far as I can see from the comments, you just want to wait for some seconds for resync so you don't need to return at all. In your case I don't see any reason why you might need an Enumerable of WaitForSeconds if you just want to skip some time. Without to know how you you call the function and the implementation of WaitForSeconds I would suggest you to change it's return type to void.
private void followSequence()
{
// Loop through each action steps in sequence.
foreach (Action step in sequence)
{
//Check if the action time is less than the current clock time.
Debug.Log("Step.tick: " + step.tick + " || Clock.tick: " + clock.getTick());
if (clock.getTick() < step.tick)
{
//If so wait out the difference to resync the action.
new WaitForSeconds(step.tick - clock.getTick());
}
// Carry out the step.
play(step);
}
}
My problem is I try to use Unity socket to implement something. Each time, when I get a new message I need to update it to the updattext (it is a Unity Text). However, When I do the following code, the void update does not calling every time.
The reason for I do not include updatetext.GetComponent<Text>().text = "From server: "+tempMesg;in the void getInformation is this function is in the thread, when I include that in getInformation() it will come with an error:
getcomponentfastpath can only be called from the main thread
I think the problem is I don't know how to run the main thread and the child thread in C# together? Or there maybe other problems.
Here is my code:
using UnityEngine;
using System.Collections;
using System;
using System.Net.Sockets;
using System.Text;
using System.Threading;
using UnityEngine.UI;
public class Client : MonoBehaviour {
System.Net.Sockets.TcpClient clientSocket = new System.Net.Sockets.TcpClient();
private Thread oThread;
// for UI update
public GameObject updatetext;
String tempMesg = "Waiting...";
// Use this for initialization
void Start () {
updatetext.GetComponent<Text>().text = "Waiting...";
clientSocket.Connect("10.132.198.29", 8888);
oThread = new Thread (new ThreadStart (getInformation));
oThread.Start ();
Debug.Log ("Running the client");
}
// Update is called once per frame
void Update () {
updatetext.GetComponent<Text>().text = "From server: "+tempMesg;
Debug.Log (tempMesg);
}
void getInformation(){
while (true) {
try {
NetworkStream networkStream = clientSocket.GetStream ();
byte[] bytesFrom = new byte[10025];
networkStream.Read (bytesFrom, 0, (int)bytesFrom.Length);
string dataFromClient = System.Text.Encoding.ASCII.GetString (bytesFrom);
dataFromClient = dataFromClient.Substring (0, dataFromClient.IndexOf ("$"));
Debug.Log (" >> Data from Server - " + dataFromClient);
tempMesg = dataFromClient;
string serverResponse = "Last Message from Server" + dataFromClient;
Byte[] sendBytes = Encoding.ASCII.GetBytes (serverResponse);
networkStream.Write (sendBytes, 0, sendBytes.Length);
networkStream.Flush ();
Debug.Log (" >> " + serverResponse);
} catch (Exception ex) {
Debug.Log ("Exception error:" + ex.ToString ());
oThread.Abort ();
oThread.Join ();
}
// Thread.Sleep (500);
}
}
}
Unity is not Thread safe, so they decided to make it impossible to call their API from another Thread by adding a mechanism to throw an exception when its API is used from another Thread.
This question has been asked so many times, but there have been no proper solution/answer to any of them. The answers are usually "use a plugin" or do something not thread-safe. Hopefully, this will be the last one.
The solution you will usually see on Stackoverflow or Unity's forum website is to simply use a boolean variable to let the main thread know that you need to execute code in the main Thread. This is not right as it is not thread-safe and does not give you control to provide which function to call. What if you have multiple Threads that need to notify the main thread?
Another solution you will see is to use a coroutine instead of a Thread. This does not work. Using coroutine for sockets will not change anything. You will still end up with your freezing problems. You must stick with your Thread code or use Async.
One of the proper ways to do this is to create a collection such as List. When you need something to be executed in the main Thread, call a function that stores the code to execute in an Action. Copy that List of Action to a local List of Action then execute the code from the local Action in that List then clear that List. This prevents other Threads from having to wait for it to finish executing.
You also need to add a volatile boolean to notify the Update function that there is code waiting in the List to be executed. When copying the List to a local List, that should be wrapped around the lock keyword to prevent another Thread from writing to it.
A script that performs what I mentioned above:
UnityThread Script:
#define ENABLE_UPDATE_FUNCTION_CALLBACK
#define ENABLE_LATEUPDATE_FUNCTION_CALLBACK
#define ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK
using System;
using System.Collections;
using UnityEngine;
using System.Collections.Generic;
public class UnityThread : MonoBehaviour
{
//our (singleton) instance
private static UnityThread instance = null;
////////////////////////////////////////////////UPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueUpdateFunc then executed from there
private static List<System.Action> actionQueuesUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesUpdateFunc to be executed
List<System.Action> actionCopiedQueueUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteUpdateFunc = true;
////////////////////////////////////////////////LATEUPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueLateUpdateFunc then executed from there
private static List<System.Action> actionQueuesLateUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesLateUpdateFunc to be executed
List<System.Action> actionCopiedQueueLateUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteLateUpdateFunc = true;
////////////////////////////////////////////////FIXEDUPDATE IMPL////////////////////////////////////////////////////////
//Holds actions received from another Thread. Will be coped to actionCopiedQueueFixedUpdateFunc then executed from there
private static List<System.Action> actionQueuesFixedUpdateFunc = new List<Action>();
//holds Actions copied from actionQueuesFixedUpdateFunc to be executed
List<System.Action> actionCopiedQueueFixedUpdateFunc = new List<System.Action>();
// Used to know if whe have new Action function to execute. This prevents the use of the lock keyword every frame
private volatile static bool noActionQueueToExecuteFixedUpdateFunc = true;
//Used to initialize UnityThread. Call once before any function here
public static void initUnityThread(bool visible = false)
{
if (instance != null)
{
return;
}
if (Application.isPlaying)
{
// add an invisible game object to the scene
GameObject obj = new GameObject("MainThreadExecuter");
if (!visible)
{
obj.hideFlags = HideFlags.HideAndDontSave;
}
DontDestroyOnLoad(obj);
instance = obj.AddComponent<UnityThread>();
}
}
public void Awake()
{
DontDestroyOnLoad(gameObject);
}
//////////////////////////////////////////////COROUTINE IMPL//////////////////////////////////////////////////////
#if (ENABLE_UPDATE_FUNCTION_CALLBACK)
public static void executeCoroutine(IEnumerator action)
{
if (instance != null)
{
executeInUpdate(() => instance.StartCoroutine(action));
}
}
////////////////////////////////////////////UPDATE IMPL////////////////////////////////////////////////////
public static void executeInUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesUpdateFunc)
{
actionQueuesUpdateFunc.Add(action);
noActionQueueToExecuteUpdateFunc = false;
}
}
public void Update()
{
if (noActionQueueToExecuteUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueUpdateFunc queue
actionCopiedQueueUpdateFunc.Clear();
lock (actionQueuesUpdateFunc)
{
//Copy actionQueuesUpdateFunc to the actionCopiedQueueUpdateFunc variable
actionCopiedQueueUpdateFunc.AddRange(actionQueuesUpdateFunc);
//Now clear the actionQueuesUpdateFunc since we've done copying it
actionQueuesUpdateFunc.Clear();
noActionQueueToExecuteUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueUpdateFunc
for (int i = 0; i < actionCopiedQueueUpdateFunc.Count; i++)
{
actionCopiedQueueUpdateFunc[i].Invoke();
}
}
#endif
////////////////////////////////////////////LATEUPDATE IMPL////////////////////////////////////////////////////
#if (ENABLE_LATEUPDATE_FUNCTION_CALLBACK)
public static void executeInLateUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesLateUpdateFunc)
{
actionQueuesLateUpdateFunc.Add(action);
noActionQueueToExecuteLateUpdateFunc = false;
}
}
public void LateUpdate()
{
if (noActionQueueToExecuteLateUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueLateUpdateFunc queue
actionCopiedQueueLateUpdateFunc.Clear();
lock (actionQueuesLateUpdateFunc)
{
//Copy actionQueuesLateUpdateFunc to the actionCopiedQueueLateUpdateFunc variable
actionCopiedQueueLateUpdateFunc.AddRange(actionQueuesLateUpdateFunc);
//Now clear the actionQueuesLateUpdateFunc since we've done copying it
actionQueuesLateUpdateFunc.Clear();
noActionQueueToExecuteLateUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueLateUpdateFunc
for (int i = 0; i < actionCopiedQueueLateUpdateFunc.Count; i++)
{
actionCopiedQueueLateUpdateFunc[i].Invoke();
}
}
#endif
////////////////////////////////////////////FIXEDUPDATE IMPL//////////////////////////////////////////////////
#if (ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK)
public static void executeInFixedUpdate(System.Action action)
{
if (action == null)
{
throw new ArgumentNullException("action");
}
lock (actionQueuesFixedUpdateFunc)
{
actionQueuesFixedUpdateFunc.Add(action);
noActionQueueToExecuteFixedUpdateFunc = false;
}
}
public void FixedUpdate()
{
if (noActionQueueToExecuteFixedUpdateFunc)
{
return;
}
//Clear the old actions from the actionCopiedQueueFixedUpdateFunc queue
actionCopiedQueueFixedUpdateFunc.Clear();
lock (actionQueuesFixedUpdateFunc)
{
//Copy actionQueuesFixedUpdateFunc to the actionCopiedQueueFixedUpdateFunc variable
actionCopiedQueueFixedUpdateFunc.AddRange(actionQueuesFixedUpdateFunc);
//Now clear the actionQueuesFixedUpdateFunc since we've done copying it
actionQueuesFixedUpdateFunc.Clear();
noActionQueueToExecuteFixedUpdateFunc = true;
}
// Loop and execute the functions from the actionCopiedQueueFixedUpdateFunc
for (int i = 0; i < actionCopiedQueueFixedUpdateFunc.Count; i++)
{
actionCopiedQueueFixedUpdateFunc[i].Invoke();
}
}
#endif
public void OnDisable()
{
if (instance == this)
{
instance = null;
}
}
}
USAGE:
This implementation allows you to call functions in the 3 most used Unity functions: Update, LateUpdate and FixedUpdate functions. This also allows you call run a coroutine function in the main Thread. It can be extended to be able to call functions in other Unity callback functions such as OnPreRender and OnPostRender.
1.First, initialize it from the Awake() function.
void Awake()
{
UnityThread.initUnityThread();
}
2.To execute a code in the main Thread from another Thread:
UnityThread.executeInUpdate(() =>
{
transform.Rotate(new Vector3(0f, 90f, 0f));
});
This will rotate the current Object the scipt is attached to, to 90 deg. You can now use Unity API(transform.Rotate) in another Thread.
3.To call a function in the main Thread from another Thread:
Action rot = Rotate;
UnityThread.executeInUpdate(rot);
void Rotate()
{
transform.Rotate(new Vector3(0f, 90f, 0f));
}
The #2 and #3 samples executes in the Update function.
4.To execute a code in the LateUpdate function from another Thread:
Example of this is a camera tracking code.
UnityThread.executeInLateUpdate(()=>
{
//Your code camera moving code
});
5.To execute a code in the FixedUpdate function from another Thread:
Example of this when doing physics stuff such as adding force to Rigidbody.
UnityThread.executeInFixedUpdate(()=>
{
//Your code physics code
});
6.To Start a coroutine function in the main Thread from another Thread:
UnityThread.executeCoroutine(myCoroutine());
IEnumerator myCoroutine()
{
Debug.Log("Hello");
yield return new WaitForSeconds(2f);
Debug.Log("Test");
}
Finally, if you don't need to execute anything in the LateUpdate and FixedUpdate functions, you should comment both lines of this code below:
//#define ENABLE_LATEUPDATE_FUNCTION_CALLBACK
//#define ENABLE_FIXEDUPDATE_FUNCTION_CALLBACK
This will increase performance.
I have been using this solution to this problem. Create a script with this code and attach it to a Game Object:
using System;
using System.Collections.Generic;
using System.Collections.Concurrent;
using UnityEngine;
public class ExecuteOnMainThread : MonoBehaviour {
public static readonly ConcurrentQueue<Action> RunOnMainThread = new ConcurrentQueue<Action>();
void Update()
{
if(!RunOnMainThread.IsEmpty)
{
while(RunOnMainThread.TryDequeue(out var action))
{
action?.Invoke();
}
}
}
}
Then when you need to call something on the main thread and access the Unity API from any other function in your application:
ExecuteOnMainThread.RunOnMainThread.Enqueue(() => {
// Code here will be called in the main thread...
});
Much of the writing about threads in Unity is incorrect.
How so?
Unity is, of course, totally frame-based.
When you work in a frame-based system, threading issues are completely different.
Threading issues on a frame-based system are completely different. (In fact, often much easier to deal with.)
Let's say you have a Unity thermometer display that shows some value
Thermo.cs
So it will have a function which is called in Update, like
func void ShowThermoValue(float fraction) {
display code to show the current thermometer value
}
Recall that the "Update" function in Unity simply means "run this once each frame".
That only runs once per frame, and that's that.
(Naturally, it runs only on the "main thread". There's nothing else in Unity! There's just ... "the Unity thread"!)
Somewhere else, perhaps in "IncomingData.cs", you will have a function which handles the concept "a new value has arrived":
[MonoPInvokeCallback(typeof(ipDel))]
public static void NewValueArrives(float f) {
... ???
}
Note that, of course, that is a class function! What else can it be?
You can't "reach in to" a normal Unity function. (Such as ShowThermoValue.) That would be meaningless - it's just a function which runs once each frame.Footnote 1
Let's say: values arrive very frequently and irregularly.
Image you have some sort of scientific devices (perhaps IR thermometers) connected connected to a rack of PCs
Those electronic devices deliver new "temperature" values very often. Let's say dozens of times per frame.
So, "NewValueArrives" is being called 100s of times a second.
So what do you do with the values?
It could not be simpler.
From the arriving-values thread, all you do is ................. wait for it ............. set a variable in the component!!
WTF? All you do is set a variable? That's it? How can it be that simple?
This is one of those unusual situations:
Much of the writing on threads in Unity is, simply, completely hopeless.
Surprisingly, the actual approach is extremely simple.
It's so simple you may think you are doing something wrong!!
So have the variable ...
[System.Nonserialized] public float latestValue;
Set it from the "arriving thread" ...
[MonoPInvokeCallback(typeof(ipDel))]
public static void NewValueArrives(float f) {
ThisScript.runningInstance.latestValue = f; // done
}
Honestly that's it.
Essentially, to be the world's greatest expert at "threading in Unity" - which is, obviously, frame-based - there's nothing more to do than the above.
And whenever ShowThermoValue is called each frame ...................... simply display that value!
Really, that's it!
[System.Nonserialized] public float latestValue;
func void ShowThermoValue() { // note NO arguments here!
display code, draws a thermometer
thermo height = latestValue
}
You're simply displaying the "latest" value.
latestValue may have been set once, twice, ten times, or a hundred times that frame ............ but, you simply display whatever is the value when ShowThermoValue runs that frame!
What else could you display?
The thermometer is updating at 60fps on-screen so you display the latest value. Footnote 2
It's actually that easy. It's just that easy. Surprising but true.
#(Critical aside - don't forget that vector3, etc, are NOT Atomic in Unity/C#)
As user #dymanoid has pointed out (read the important discussion below) it's critical to remember that while float is atomic in the Unity/C# milieu, anything else (say, Vector3 etc) IS NOT ATOMIC. Typically (as in the example here) you only pass floats around from calculations from, say, native plugins, thermometers etc. But it's essential to be aware that vectors and so on are NOT atomic.
Sometimes experienced threading programmers get in a knot with a frame-based system, because: in a frame based system most of the problems caused by racetrack and locking issues ... do not exist conceptually.
In a frame-based system, any game items should simply be displaying or behaving based on some "current value," which is set somewhere. If you have info arriving from other threads, just set those values - you're done.
You can not meaningfully "talk to the main thread" in Unity because that main thread ............. is frame-based!
Most locking, blocking and racetrack issues are non-existent in the frame-based paradigm because: if you set latestValue ten times, a million times, a billion times, in one particular frame .. what can you do? .. you can only display one value during that frame!
Think of an old-fashioned plastic film. You literally just have ...... a frame, and that's it. If you set latestValue a trillion times in one particular frame, ShowThermoValue will simply display (for that 60th of a second) the one value it grabs when it is run.
All you do is: leave information somewhere, which, the frame-paradigm system will utilize during that frame if it wants to.
That's it in a nutshell.
Thus, most "threading issues" disappear in Unity.
All you can do from
other calculation threads or
from plugin threads,
is just "drop-off values" which the game may use.
That's it!
Let's consider the question title...
How do you "... call a function in the main Thread"
This is completely meaningless. The "functions" in Unity are simply functions which the frame engine runs once per frame.
You can't "call" anything in Unity. The frame engine runs a number of things (many things) once per frame.
Note that indeed threads are totally irrelevant. If Unity ran with a billion threads, or with quantum computing, it would have no bearing on anything.
You can't "call a function" in a frame-based system.
Fortunately, the approach to take is dead simple, you just set values, which the frame-based functions can look at when they want! It's really that easy.
Footnotes
1 How could you? As a thought experiment, forget about the issue that you're on a different thread. ShowThermoValue is run once a frame by the frame engine. You can't "call" it in any meaningful way. Unlike in normal OO software, you cannot, say, instantiate an instance of the class (a Component?? meaningless) and run that function - that is completely meaningless.
In "normal" threaded programming, threads can talk back and fore and so on, and in doing so you have concerns about locking, racetrack and so on. But that is all meaningless in an ECS, frame-based, system. There is nothing to "talk to".
Let's say that Unity was in fact multithreaded!!!! So the Unity guys have all of the engine running in a multithreaded manner. It wouldn't make any difference - you can not get "in to" ShowThermoValue in any meaningful way! It's a Component which the frame engine runs once a frame and that's that.
So NewValueArrives is not anywhere - it's a class function!
Let's answer the question in the headline:
"Use Unity API from another Thread or call a function in the main Thread?"
The concept is >> completely meaningless <<. Unity (like all game engines) is frame-based. There's no concept of "calling" a function on the main thread. To make an analogy: it would be like a cinematographer in the celluloid-film era asking how to "move" something actually on one of the frames.
Of course that is meaningless. All you can do is change something for the next photo, the next frame.
2 I refer to the "arriving-values thread" ... in fact! NewValueArrives may, or may not, run on the main thread!!!! It may run on the thread of the plugin, or on some other thread! It may actually be completely single-threaded by the time you deal with the NewValueArrives call! It just doesn't matter! What you do, and all you can do, in a frame-based paradigm, is, "leave laying around" information which Components such as ShowThermoValue, may use, as, they see fit.
Another solution to run code on the main thread, but without requiring a game object and MonoBehavior, is to use SynchronizationContext:
// On main thread, during initialization:
var syncContext = System.Threading.SynchronizationContext.Current;
// On your worker thread
syncContext.Post(_ =>
{
// This code here will run on the main thread
Debug.Log("Hello from main thread!");
}, null);
Use UniRx's multithreading pattern, UniTask and RxSocket together.
[SerializeField] private Text m_Text;
async UniTaskVoid Connect() {
IPEndPoint endPoint = new IPEndPoint(IPAddress.IPv6Loopback, 12345);
// Create a socket client by connecting to the server at the IPEndPoint.
// See the UniRx Async tooling to use await
IRxSocketClient client = await endPoint.ConnectRxSocketClientAsync();
client.ReceiveObservable
.ToStrings()
.ObserveOnMainThread()
.Subscribe(onNext: message =>
{
m_Text.text = message;
}).AddTo(this);
// Send a message to the server.
client.Send("Hello!".ToByteArray());
}
I'm making a memory reader for a game, and I've got an almost infinite thread running in the background which checks for the players position, and then displays it on a label by using Invoke(). I'll only post the offending function. This gets called on the same thread every 10 ms.
Invoke((MethodInvoker)delegate
{
lblCoords.Text = "Player Coordinates: < " + (int)x + ", " + (int)y + ", " + (int)z + " >";
});
After the code has been running for about 20 minutes, it will crash and throw a StackOverflowException related to this function. Why is it happening and how can I stop it? Obviously I could just stop using a label to show it, though it would be more useful to know why it's happening for future reference.
So this is the thread method, someone mentioned that it's multiple objects getting created at once, I'm going to assume it's this because it is an infinite loop of calling UpdateThread()... Should this have a while loop instead of calling itself?
private void UpdateThread()
{
if (!running) return;
ReadPos();
Thread.Sleep(100);
UpdateThread();
}
private void ReadPos()
{
int pointerAddress = Memory.HexToDec(MemoryOffsets.PlayerPosAddress);
byte[] xVal = memory.PointerRead((IntPtr)pointerAddress, 4, MemoryOffsets.PlayerX);
byte[] yVal = memory.PointerRead((IntPtr)pointerAddress, 4, MemoryOffsets.PlayerY);
byte[] zVal = memory.PointerRead((IntPtr)pointerAddress, 4, MemoryOffsets.PlayerZ);
float x = BitConverter.ToSingle(xVal, 0);
float y = BitConverter.ToSingle(yVal, 0);
float z = BitConverter.ToSingle(zVal, 0);
Invoke((MethodInvoker)delegate
{
lblCoords.Text = "Player Coordinates: < " + (int)x + ", " + (int)y + ", " + (int)z + " >";
});
}
The error the program was showing me pointed at the Invoke method, which is why I thought it was just that causing it. Since it takes about 20 minutes for the exception to occur, I can't get too much information about it.
Should this have a while loop instead of calling itself? Yes, by all means.
Sanly C# will not generate tail calls for this code, meaning it will stack the calls of UpdateThread until the call stack is full. This is causing the StackOverflowException.
So, you would implement something like this:
private void UpdateThread()
{
while (running) //I'm assuming running is a volatile variable
{
ReadPos();
Thread.Sleep(100);
}
}
Note: It is good idea to make running volatile, as it will be set by another thread (I presume).
You could also consider to post the execution to the thread loop or a similar scheduling mechanism instead of having a dedicated thread, on that regard, do your testing to see what works best.
Another thing to consider is to keep your delegate object alive, it will reduce pressure on the garbage collector (since you are currently creating too many short lived objects), but it is not the cause of the StackOverflowException.
Yes, you should use a loop instead.
You are using recursion to make a loop, and as the loop doesn't have a reasonable limit it will fill up the stack with call frames.
Just loop inside the method:
private void UpdateThread()
{
while (running) {
ReadPos();
Thread.Sleep(100);
}
}