Stoopid Yield Question

Unity Engine
1

Would someone please tell me exactly what the yield statement at the end of the while loop in this snippet of code actually accomplishes?

function myFunction () {
	
	//  non-loop stuff
	
	while (true)
	{

	//  loop stuff

	yield; 
				
	}
}
2

My instincts tell me that the “non-loop stuff” code executes one time, initially.

Then, the “loop stuff” executes every time the function is called thereafter.

Is this correct?

3

That generic loop will never end unless you have something in the loop to make it false, but you probably already know this. yield just adds a forced pause in the program, it literally pauses the thread execution for a given time that you can set.

Atleast that has been my experience with it. If I have a yield in my code, my program yields to the threads queue stack.

4

Yeah, I’m hip to all of that. I’m just curious about this particular implementnation.

So, I could use the non-While loop code as one-time initialization for myFunction.

Then, the While loop code would execute with subsequent calls to myFunction.

Correct?

5

I also believe that without the yield, the user would not be able to interact with the game until the loop ended. Especially if it is a long running task, they yield will keep the game from being “locked up”, from the user’s perspective.

6

Yes, yes, I know about the infinit loop.

And thanks for the feedback, all. :slight_smile:

Still, what I’m curious about is this whole function initialization and function loop thing - anyhone know if I’ve got that right?

7

Not quite Marty. Every time you call the function the non-loop code will get executed then your looping stuff will execute, yielding each loop iteration, until you trigger a condition to exit the while-loop.

8

NOW, I get it.

The non-loop code is executed every time you call myFunction, whereas the loop code executes continually until its condition resolves false.

And, in the case of a loop that is infinite (as in my example) the loop executes forever. Call myFunction enough times and you’ll have whole bunches of threads running iterations of the loop.

Thanks, Tom! And all.

9

Thats all correct. Only one thing, internally coroutines dont use threads. They are much lighter than that. They basically store all local variables in an class instead of on the stack. That makes them not have much overhead and you can always pause and resume them.

But for the purpose of understanding its useful to think of it as threads which get paused and when it gets paused the rest of the program can continue.

10

Thanks, Joe!

So, the onus is on the coder to make sure that all coroutines are self-limiting, lest you not end up with a bunch of them running needlessly, right?

Or is there some way to, say, assigned a variable reference to a coroutine when it is called, so that you can maintain a list of and terminate them externally?

11

Coroutines are always attached to a specific instance. Thus when the game object is destroyed or the component removed, the coroutine will be stopped automatically. If you load a new level or something, there is nothing to worry about with stopping coroutines. All happens automatically.

You can use StopCoroutine to stop a coroutine manually, but most of the time a coroutine stops by the object being destroyed or the coroutine reaching the end of the function.