Will implementing EntityCreator become possible

[wzjsun]

I have two systems that need to create a certain type of entity, which includes a fixed set of components. Currently, my implementation is as follows:

pub fn s1(c1: Command) {
	c1.spawn((DrawObject::new(), Background::new()))
}

pub fn s2(c2: Command) {
	c2.spawn((DrawObject::new(), Text::new()))
}

However, the apply function of these two systems can only be executed sequentially, and they cannot be parallelized with other systems. I think the following approach should solve this problem:

pub fn s1(c1: EntityCreator<(DrawObject, Background)>) {
	c1.spawn((DrawObject::new(), Background::new()))
}

pub fn s2(c2: EntityCreator<(DrawObject, Text)>) {
	c2.spawn((DrawObject::new(), Text::new()))
}

In theory, the write operations of c1 and c2 to the world do not conflict with each other.
I am not familiar with the internal implementation of ECS, so I am not sure if this approach is feasible.

[MrGVSV]

Is there a reason you aren't using bundles here?

Also, whats the reason they have to be sequential? If they are both spawned in the same frame then order shouldn't really matter since those changes don't take effect until the Commands are flushed.

[wzjsun]

The sequential execution I am referring to here does not mean the sequential execution of two systems, but rather the application_ system_ When buffers apply instructions to the world, the execution of these two instructions is serialized.

[SkiFire13]

In theory, the write operations of c1 and c2 to the world do not conflict with each other.

AFAIK this is unfortunately not true:

• allocating an entity (not just reserving one, like Commands::spawn/Commands::spawn_empty do) requires exclusive access to Entities. I'm not sure how this could be made concurrent.
• this might register a new component/archetype/table, which requires exclusive access to Storages. However this could be done when initializing the SystemParam, so I don't think it would be a real problem.
• it's not true that different archetypes means writing to different tables. For example if in your example DrawObject used sparse storage then the two spawners would both try to write to the same storage. Likewise if both Background and Text used sparse storage then the table for DrawObject would be shared between the two archetypes. I think the scheduler could reason about these details, but they're still very tricky to get right.

[wzjsun]

Yes, you are right，Allocating an entity should be an atomic operation, and parallelism should not be a problem，But sparse storage is indeed a tricky issue

[wzjsun]

Perhaps, it can prevent components from declaring sparse storage and only allow components with dense storage. In fact, the components that need to be inserted when creating entities are mostly densely stored

[SkiFire13]

Allocating an entity should be an atomic operation

That's much easier than done IMO, since currently this is inherently a very sequential operation. It requires:

• allocating all the reserved entities and removing them from the "pending" vector
• allocating space in the entity metadata Vec for the new entity (may require a resize)
• allocating space in the archetype entity metadata Vec for the new entity (may also require a resize, also for reserved entities this is the empty archetype)

All of these operations are not easy to make thread-safe. Moreover there's a lot of code that relies on accessing these Vecs to be as fast and cheap as possible, so any form of synchronization may be unwanted for them.