Events, Commands and concurrent queues

[alice-i-cecile]

Problem

Events and commands have a very similar conceptual model:

• Gather a list of things that we want to handle at a later point.
• Collect these, and then process them at some point in the future.
• Eventually remove these events.

As I see it, there are several things that could be improved with the current design:

1. Under the hood though, Commands is not implemented as an Event, despite its obvious similarities.
2. As I understand it, Commands and Events are currently handled as resources by our scheduler. This means that they follow the usual rules for read / write access and, especially in the case of commands, can seriously limit the parallelization of our systems. In 90% of use cases though, the only behavior we need is "write-to-end", which can be handled in a much more concurrent way.
3. Passing in the Commands type to our systems is unique magic that doesn't obey the typical rules for the IntoSystem trait / macro.

Proposal

1. Make Commands operate via events. This reduces code duplication, allows users to implement their own EventReader on commands, and generally reduces their magic. Rather than using the default double-buffering events behavior, process commands at the end of each stage, then clear the whole buffer.
2. Condense the types accepted by the .system() method to Query<&C, F>, Res<&R, F>, Event<&E> and EventReader<&E>. Change the idiomatic parameter to commands: Event<&Command>` and do away with the newtype pattern for events. See Resources v2 for more thoughts in this direction.
3. Create a new method for Event that allows you to add a new event to the end of the queue in a nonblocking fashion, allowing multiple systems referencing the same Event<T> to run in parallel. Under the hood, this might be nicely implemented by having one copy of each type of event buffer resource per thread, then collect them all automatically via Res and EventReader.
4. When you want to directly operate on various objects that are usually wrapped in an Event, call it as Res<T> (or the mutable form) instead, which gives the existing blocking behavior back.

Open Questions

1. How do we want to order events to be processed, if they're able to be generated in parallel? In many cases this won't matter, but in others the ordering might be important.
2. Is it possible to eliminate system chaining by combining events and explicit system ordering?

[DJMcNab]

Commands are currently system local, i.e. point 2. in the first list isn't quite correct. And point 3 is out of date - the new SystemParam stuff allows Commands to be anywhere.

As an aside, I believe

bevy/crates/bevy_ecs/src/system/system_param.rs

Line 114 in 6c07c80

Some(&mut *system_state.commands.get())

is unsound - we need to check the borrow for commands (i.e. use a RefCell or Sync equivalent - maybe Mutex would be fast enough since it should only be called on thread?) since we hand out &mut T

For reasons of

fn oh_dear(commands: &mut Commands, commands: &mut Commands) { /* Insert nasal demons here */ }

I haven't checked that, so there might be something else going on which prevents this however.

[alice-i-cecile]

Commands are currently system local, i.e. point 2. in the first list isn't quite correct. And point 3 is out of date - the new SystemParam stuff allows Commands to be anywhere.

Thanks for the clarification; I had a hell of a time tracking down exactly how Commands were processed. That makes this work less pressing.