Is this a proper way to do an Async function?

[whole abyss]

I have an expensive (I believe) function, that however is related purely to visuals, so I'd like to call it parallelly with the main code, to not bog it down. Info online on it is kinda super confusing at times, but I gathered that async is the way to go. Would that work?

    //TODO: Make Recalculate() async
    
    private bool meshIsRecalculating;
    private bool recalculationQueued;
    /// <summary> Queue recalculation of the decal mesh </summary>
    public async Task<bool> RecalculateAsync()
    {
        if (meshIsRecalculating)
        {
            if(recalculationQueued) return false;
            recalculationQueued = true;
            return false;
        }
        meshIsRecalculating = true;
        await Task.Run(Recalculate);
        meshIsRecalculating = false;
        return true;
    }
    
    /// <summary> Recalculate the decal mesh </summary>
    public void Recalculate()
    {

        //The expensive calcs here, to cut out intersecting meshes into a final decal mesh

        if (recalculationQueued)
        {
            recalculationQueued = false;
            Recalculate();
        }        
    }

(p.s. I'd love to just use Unity's standard decals instead, but they're incompatible with my stylized lighting shader)

[radiant grail]

seems like you accidentally double posted?
https://discord.com/channels/489222168727519232/1424785438903767090
might want to remove one to avoid confusion

[cinder jungle]

Yes, I think that would work. However:

1. Task.Run will execute the func on a worker thread, so you'll be limited in what Unity APIs you can use in Recalculate()
2. It would be the The Unity Way to use Unity's own Awaitable instead of .NET Tasks (or the third party library UniTask). See https://docs.unity3d.com/6000.0/Documentation/Manual/async-awaitable-introduction.html for a comparison of them

[whole abyss]

My version of Unity has no "Awaitable". What are the limitations on API in Tasks?

[fossil socket]

It's not in tasks specifically but in calling unity API from a non main thread. The limitation is as simple as: don't use unity API from threads or you'll get runtime errors.
Note that, unless you use Task.Run specifically, unity would run your tasks on the main thread, like coroutines, so it's "not really" parallel.

[whole abyss]

The limitation is as simple as: don't use unity API from threads or you'll get runtime errors.
So I can't use any Unity functions or call Unity classes?

[fossil socket]

Most of them. Some static and utility classes/struct/methods might be fine. Like the Mathf stuff. Anything that touches unity Object(GameObjects, components, scriptable objects, assets, etc...) is not allowed.

[whole abyss]

Ah, damn, ok, that's exactly what I was intending to use it with... Time to think of another approach, I guess...

[fossil socket]

It would be best to separate the heavy calculations from setting data to the unity components/objects. This way you can do the heavy stuff on a a background thread, and just do quick setters and some other minor logic on the main thread.

[tiny willow]

there are some unity things you can do on background threads via jobs, but that depends on there being specific unity APIs designed for that task (eg https://docs.unity3d.com/6000.2/Documentation/ScriptReference/Mesh.MeshData.html for meshes) whereas async/tasks is more of a general-purpose tool

[cedar summit]

You can use UniTask instead https://github.com/Cysharp/UniTask

[shy jasper]

incorrect, Task.Run will run on thread pool thread

[shy jasper]

the limitation is that your continuation wont be scheduled properly (start frame, end frame, etc...)

its truly random

a poorman's hack for this is to make your own thread dispatcher in an update loop

[cedar summit]

As UniTasks no 1 fan id recommend that 😆

[shy jasper]

public static Queue<Action> queue;

public void Update()
{
  while(queue.TryDequeue(var action))
  {
    action.Invoke();
  }
}

its bad, simply bcos it will allocate each time you instantiate new delegate AND fat chance you'll end up with tons of closures.

and its well known that callvirt on delegate is slower than regular call (not that it matters, but still important to mention)

[shy jasper]

most structs such eg : vectors, quats and Color etc should be thread safe.. I forget the rest

[fossil socket]

Data structures, yes. These don't touch unity Objects.

[tiny willow]

this isn't true, it works the same as Awaitables (continuing after an await on the main thread always continues on the main thread), the main difference is that Awaitables are more efficient (less allocations) and the static methods offer some easy ways to do things like waiting for certain parts of the player loop

Awaitables does give you an easier way to switch back to the main thread, but if you're stuck with just tasks you can still do that, it's just extra lines of code

[shy jasper]

you can't really compare with Awaitable<T>.. its a proper async api specifically made for the engine

unity never has a proper support for async/await before awaitable

as the dude said, he's using the version where there's no awaitable in it

[shy jasper]

☝️ that

[shy jasper]

there's no magic with Awaitable in unity, the difference is that it respects unity's gameLoop and Unity is using a single threaded SyncContext so it will have no issue to sync back to the mainthread.

Switching back to mainthread is easy enough even without awaitable, you can just capture the SyncContext with SynchronizationContext.Current then Send/Post from it

[shy jasper]

Task.Run will mess tons of things if you're not careful

[whole abyss]

On one hand I want to try to make it async after all and try to pass everything in as structs and get back the results (also as struct) once they're done, and apply them to the decal mesh. On the other hand, part of this function is getting volume intersecting mesh renderers and obtaining meshes from them, so it's unclear if there will even be any point in making that function async in the first place if I'll move those heavy calls out of it...

[tiny willow]

i'm replying to your post comparing the two and saying that continuations work differently, which they don't