How is AsyncComputeTaskPool supposed to be used?

[pubrrr]

I want to do a couple of long running tasks using bevy:

• running for ~1 seconds, so definitely too much to run within a frame,
• returning a value (metadata, easy to process within a frame) that I can then use then for further computations.

I am not really experienced with async programming, so from the async examples I figured, that I can either put the work in a thread and do all the work myself, or I use the AsyncComputeTaskPool, that (judging from the naming) sounded like exactly what I need.

The bevy_tasks examples do not seem very useful either for my case.

So here is my question:

How is AsyncComputeTaskPool supposed to be used?

The async compute example seems like the idiomatic way to me:

• Have a system, creating tasks using AsyncComputeTaskPool::spawn
• Put the tasks somewhere in the world, e.g. a component of an entity
• Have another system, that regularly polls the task entitiess to check whether they are finished.

The problems I see:

• What should I do with the tasks? They seem very low level objects where you need to do a lot of technical stuff to get something useful back. Would it be possible to introduce some more abstraction here? Usually bevy does quite well in exposing easy-to-use APIs for complicated under-the-hood stuff.
• The example suggests using the combination futures_lite::future::block_on(futures_lite::future::poll_once(&mut *task)). This seems quite reasonable, but it took me a while to understand why.
  • Isn't this the typical thing that you want to do in the bevy context? Maybe expose this somehow as a convenience function?
  • Is it possible to get somehow rid of the many pointers in &mut *task?
• As a consumer, I need to either work hard polling the Task (creating the context, waiter, etc.) or I need to require additional dependencies (like futures-lite in the example). This is already present in bevy anyway, so just reexport the useful functionality?
• As bevy works with systems that run every frame, as far as I can judge, the usage will always look somewhat similar to

  task_system(task: Query<Task>) {
      if let Some(result) = task.poll but don't wait {
          use result
          despawn task entity
      }
  }
  

  because otherwise you will poll on a task that already returned its result in the previous frame and thus will panic.
  • Is there a way to make the task indifferent to the underlying future, if the actual task has already finished? I imagine something like saving the returned result upon completion and returning this on subsequent polls, instead of panicking?
  • Alternatively, is there a way to make the if task.finished { despawn task entity } somehow built into the task? This is easy to forget while programming and there is no reason to keep a task that has already finished.

All in all I found the Tasks unergonomic to use, maybe this can be improved. Alternative suggestions how to solve my above mentioned problem are welcome :)

[pubrrr]

From the discussion on discord:

• offering a convenience function that reexports futures_lite::future::block_on(futures_lite::future::poll_once(&mut *task)) makes sense.
• Storing the result in the task might be possible, but it is (at least to me) unclear how to implement that without cloning the result.
• if task.finished { despawn task entity } is not so easy, because then bevy would need a whole system to do that. Maybe that could be solved by a prebuilt plugin, that processes certain Components, and then despawns them and sends an event out, so that the consumer can listen to some kind of "finished task" events.

[pubrrr]

Relevant PRs: #2691 #4062