Assets What do you hate about Coroutines?

Hi guys,

We're currently developing a project and decided to develop our own Coroutine system because of some of the limitations that the default Unity system has, such as:

• no threading,
• no return values,
• garbage creation,
• the need for a MonoBehaviour parent
• etc.

We're studying the possibility of publishing the kit on the Asset Store. But first, we'd like to know what bothers you the most about Unity's Coroutine system.

So, with that said, what are your biggest hurdles with using Coroutines in Unity?

 

I also found the coroutines lacking in many areas, mostly some of those you already mentioned.

So lately I've been using the .net Thread Parallell Library (TPL) which seems to work fine in unity too, need to add it separately though. https://www.nuget.org/packages/TaskParallelLibrary/

With this you can create tasks that run in separate threads, with return values etc.

 

That's nice!
I didn't know that there was a standalone version of the TPL (and compatible with the .NET 3.5 profile). Will definitely explore it.

Just a question, though.
How do you handle calling the Unity API in a task?

 

I don't. I run the tasks on other threads, as far as I have understood Unity is not thread safe so you can't call its api on another thread and expect it to behave as it should.

I use it for loading/saving data to databases, writing to files, process huge amounts of data etc. e.g slow operations that I don't want to slow down/hang the main thread for long.

So once the task I created has processed/loaded the data it then returns its return value to the main thread again (using a synchronization context). Then I continue creating/updating the gameobject or call whatever Unity API call I need safely on the main thread based on the tasks returned data. This way the slow operations don't hang/block the game.

 

Oh, ok.

Do you by any change know how much overhead using Tasks has on the performance?
Like, mainly in terms of garbage creation (which is the biggest problem, most of the times).

 

There is also this released in 2014: https://www.assetstore.unity3d.com/en/#!/content/15717

 

I haven't really done any profiling in this area. In my use cases it went from small hiccups anytime I wanted to save/load anything during runtime to no hiccups at all I don't use Tasks/Coroutines in my games in many places mostly only when saving/loading stuff to avoid having to block/pause gameplay.

 

That's really cool and solves that problem of accessing the Unity API in threads.
Like, you still can't access them in another thread, but you have a "quick" and obvious way to switch contexts.

The downside is that it inherits the same problems from Unity's own coroutines, I think.

 

Must yield scaled and unscaled time.

 

Do you mean that you'd like to see the ability to yield scaled and unscaled time?

As far as I remember, Unity's WaitForSeconds yield instruction only works with scaled time, I think.

 

It has scaled and unscaled.

 

Oh, ok. We tend to use coroutines a lot in our projects, so overhead must be kept to a minimum.

I'll investigate and profile the TPL package. When I have the data I'll post it over here

 

Well it seems that Unity is working on "C# Jobs compiler" to natively support multi-threading.

I don't know where I can find that online but they just spoke about that in the 2017 Keynote about one hour ago:

Your package may become deprecated before even being released...

 

This is what we use, and it's pretty great: https://www.assetstore.unity3d.com/en/#!/content/68480

It address all the main issues with co-routines, except threading.

 

Just had the opportunity to see it. Almost forgot it was today haha
Thanks for the heads up. Was looking forward to the keynote, and oh boy was it worth it.

What we saw regarding the new native Job system was amazing, just like the other tech demos they've showed off in the past.
The new compiler technology thing was just amazing! It looks to be going in the right way.

Now, I see what you mean when you say that the package might become deprecated before even being released.
But the thing is, this new Job system is, at best, several months away from being released.
And when it does, it might take some time for users to get used to it.
So there might be an opportunity to release our kit still.

Like I said in the OP, we're still just exploring the idea and gauging your interest
There's nothing set in stone in this phase.

 

This asset solved a lot of the problems.
https://www.assetstore.unity3d.com/en/#!/content/68480

 

That asset is awesome!
It really extends functionality and is really easy to use for someone used to using coroutines.
But I think it's still missing some important features such as return values and optional multi-threading
.
The non-object oriented API also bugs me a little bit, but that might just be me haha
Although, in the author's defense, Unity's coroutines are not really OO either.

 

My biggest issue with Unity's coroutines is the inability to save and recreate their state. I've created a simple custom coroutine system myself just to see what's up, but I don't see a way to do this.

It would be great if the coroutine or the wrapping object would somehow store the iterator's progress and then be able to jump to that at request. Like you have .MoveNext(), you would also have .MoveTo(int).

 

Hmmm... That's interesting.
Pausing a custom coroutine would certainly be straight forward to implement.
However, it doesn't look like quite what your looking for.

Could you please give an example on where it would be useful to recreate a coroutine's state?