Closed MiniaczQ closed 2 years ago
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.
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... 🗑️
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.
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...
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.
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.
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?