A coroutine is just like a method except that you can yield in it. (not counting the stopping and how you call it).
So if you mentally take the yield out, just ask yourself, will this coroutine ever end by reaching the last line in it. If so, you don’t need to stop it.
public bool IsAlive; // play, watch health, and click this at some point.
public float Health;
public void Start()
{
// Create the coroutine.
StartCoroutine(HealthTicker());
}
public void Update()
{
// No maintenance on the coroutine.
}
public IEnumerator HealthTicker()
{
// It will be stuck here until IsAlive == false.
while (IsAlive)
{
Health += Time.deltaTime * 5;
yield return null; // This simply makes it yield until the next frame where it will then loop back into this while statement.
}
// When IsAlive is false, it drops out of the while loop and can reach the end of it's code.
Debug.Log("I have perished, and thus my coroutine has run it's course.", this);
}
When you start a coroutine it will do whatever you tell it and obey the yield instructions you give it forever. If a coroutine instance reaches the end of it’s code then it automatically goes away forever.
In the above example the coroutine is basically a waste of resources because you could easily do this:
public bool IsAlive;
public float Health;
public void Start()
{
}
public void Update()
{
if (IsAlive) RegenHealth();
}
public void RegenHealth()
{
Health += Time.deltaTime * 5;
}
So be mindful and only use them if they can’t be replaced by simpler approaches.
I al using IEnumerators because I work with a huge amount of data taken from a Data Base, so I need to somehow use that data to set properties to the game objects, so I yield return null every 1000 loops and end when the iteration goes trough the whole list. If there is a better option for this I take it, problem is that I can not access to GameObject properties, components, instances, transforms and anything from a separed thread, so I load data from hte Data Base into Unity on a separated Thread, then I use IEnumarators to asign that data to the game objects (data has about 14 columns and 20k rows, this can go up to 1kk rows)
You don’t have to use StartCoroutine if you want more flexibility on what to do with the iterator. You can always call MoveNext() yourself whenever you want it to iterate.
But, yes, in order to access the Unity API, it must be done from the main thread.
You’ll have to use some kind of a thread safe container that can be shared between the main thread and other threads. You can actually design for this – have the main thread check if there’s new data in the container, then act accordingly on it and update the UI.
Sure it is. You can spin as many threads as you like. You just have to interact with Unity through the main thread. It’s actually a pretty decent way to keep things safe.
Threading is nasty business at the best of times. You would not like it if Unity called your code from multiple threads, or if you could call into Unity from multiple threads.
As to the OP question, a coroutine will stop automatically if it runs out of code to execute, or if the MonoBehaviour it is on is disabled/destroyed.
Thank you guys for all your responces, I have managed the read the info only if the thread has finished it’s job, but My main questions is still here, do I have to stop a Coroutune when it is finished or it stops by itself one finished?
If it will reach the end of the function, it stops itself because it’s done. It naturally concludes like any other function. If it’s running a loop with no end condition, you need to stop it manually with StopCoroutine.