Coroutines evolution

Summary

This thread is to continue the discussions going on in the Coroutines’ implementation PR #801, and to avoid cluttering the PR itself.

In particular, it emerged that further down the road, it could be worthy to investigate the following two aspects that are currently not managed, related to the management aspects of the new Coroutines system.

Saving/Loading Coroutines

As it is now, the system does not support saving and loading of Coroutines; it might be possible that during de/serialization the status is preserved “automagically”, were the coroutineManager be serializable in the Scene, but testing is definitely required to be sure of the results of this operation. From a quick glance at Unity’s references, it appears that this topic still doesn’t have an out-of-the-box solution, and relies on the user’s management to determine which variables need to be saved and how to restore the Coroutine to the desired state. https://docs.unity3d.com/Manual/Coroutines.html https://docs.unity3d.com/ScriptReference/Coroutine.html https://answers.unity.com/questions/1433878/how-to-store-the-state-of-ienumertor-and-resume-th.html https://forum.unity.com/threads/how-can-i-save-and-load-a-coroutine-state.796401/

Automatically clearing up Coroutines when the spawning GameObject gets removed

Currently the system doesn’t track, and is not interested in, the context in which a Coroutine has been spawned; the Coroutine has the capability to affect any number of Entities in any Scene, and its execution is anyway managed so that an error would not result in an unrecoverable state of the engine.

A possible solution, as proposed by @Barsonax, would be to assign to each GameObject (and/or Component) a list of Coroutines that would be automatically Cancelled once their respective “container” is being removed from the Scene. (Bonus: they could be paused/resumed automatically on de/activation). This would be an extra facility, in addition to the current way to start Coroutines.

[Barsonax]

Another thing we might want to look into in the future: https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.iasyncenumerable-1?view=dotnet-plat-ext-3.1

Basically the combination of a itterator and async

[Barsonax]

A possible solution, as proposed by @Barsonax, would be to assign to each GameObject (and/or Component) a list of Coroutines that would be automatically Cancelled once their respective “container” is being removed from the Scene. (Bonus: they could be paused/resumed automatically on de/activation). This would be an extra facility, in addition to the current way to start Coroutines.

I think we should do this on component level and generalize it so it will work for more than just coroutines. In the future we might also have a job system which makes use of this and the enduser might also want to use this API.