#Is it possible to use Commands or ParCommands in an AsyncComputeTask ?

16 messages · Page 1 of 1 (latest)

formal creek
#

title

#

alternatively how would I send a signal from the detached task that i can then process

formal creek
#

I ended up using a resource with Arc<SegQueue<...>>, and then processing the results in a separate system. leaving open as I'm not sure this is actually a good way to do it

umbral skiff
#

how exactly do you want to use commands in a separate thread? aren't systems parallel by default?

formal creek
#

I have a non-blocking task created on the AsyncComputeTaskPool, that I then .detach() so I don't need to poll. I still want to apply the output of this function, though. If I had the ability to use Commands within this task that would work totally fine but it doesn't work. Using an Arc<SegQueue<...>> works but feels jank.

umbral skiff
#

what do you want to do with Commands? spawn an entity?

spring plank
#

Typically in these scenarios I build a list of calls to commands in the thread and then iterate through them in a system after the task is resolved.

formal creek
#

The task originally worked by returning data that would then be used to populate a component on an entity. Polling all of these tasks however quickly became an issue as polling a bunch of tasks that may or may not have finished is slow (and limiting the amount polled leads to stuttering as only the first N tasks get polled and then they all complete at once, causing stutter)

To solve this, I detach the task so it runs in the background (without having to be polled) and have it update a Queue that can then be applied with another system.

However, the ideal solution would be calling Commands directly from the task eliminating the need for an async queue

junior comet
#

Here is what I'm looking at, personally: the current issue is that the compiler doesn't understand Task::poll method call on L39. Even though Task implements Future, the compiler doesn't want to hear it. So I imagine I'm just going about this in the wrong way.

#

FYI @peak temple

junior comet
peak temple
#

I was using block_on too.

formal creek
#

Note for anybody else having issues with this, block_on can be quite slow, detaching the task and having it return results in an async queue is significantly faster