Unused CountdownEvent

[MiniaczQ]

How can Bevy's documentation be improved?

definition
re-export

Searching through source revealed that CountdownEvent is only used in it's definition file and in the module's re-export.
Should it be kept or deleted?

[alice-i-cecile]

This feels like it could be useful externally, but I'm not confident enough in the design. If we keep it, it should have a proper example demonstrating its use.

Punting this question to @aclysma, the original author of the code in #437.

[mockersf]

My usual stance to something never used in Bevy is "remove it, see if someone complains on the PR"...
Then, if someone says it's useful, open a PR to add an example maybe.

In this case, this is very hard to discover, not obvious how to use, no example, and never came up on discord so... 🗑️

[MiniaczQ]

The usage is pretty simple, its a stripped down async barrier primitive, where counting and awaiting is separated. Not sure where I'd use it though.

[mockersf]

it's "pretty simple" but it's unlike anything else in Bevy. And I wouldn't call anything using async in rust "pretty simple" to be fair...

[aclysma]

This sync primitive is equivalent to the one discussed in this GDC talk, see at 16:50 for an example: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine

It is broadly useful for scatter/gather workloads which are typical in games. TaskPool::scope() could also be used in some cases, but has a different tradeoff for flexibility/safety/ease-of-use.

I think the most common case of wanting this would be to jobify existing code where, for whatever reason, the more rigid but safer callback-based approach of TaskPool::scope() is unsuitable. Two cases come to mind: satisfying borrow-checking rules, or deferring the await to some time later.

[alice-i-cecile]

Thanks for the explanation. It sounds like this could definitely be useful, but if so it deserves proper docs demonstrating usage and tradeoffs, likely in the form of a complete example.