Can emplace as callback of on_destroy break?

[LiliumAtratum]

I have a tag (Collector) that its set each time another component (Instigator) is changed:

        registry.on_construct<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();
        registry.on_update<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();
        registry.on_destroy<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();

Later in the code, I periodically iterate over all entities having Collector tag and run a system update function:

template<typename Collector, typename Func>
void collectorEach(Func &&func) {
    registry.view<Collector>().each([&](entt::entity entity) { func(entity); });
    registry.clear<Collector>();
}

Note, this is similar to observers, but:

• it reacts uniformly when a component is added, updated or removed. Basically, I am interested in any change.
• it will not detect a scenario where two or more operations on the Instigator cancel each other out. It is easier to just launch func redundantly than to detect this scenario.
• When Instigator is not touched ever by a given entity, Collector is never added. To my knowledge, this is not possible with observers. If I would write entt::collector.group<>(entt::exclude<Instigator>) (is it even valid?), then every component would be collected once, when created.

However, I just catch a bug where view<Collector>().each gave me an entity that is not valid. ENTT_ASSERT(valid(entity)); in a try_get fails. Since func does not remove any entities, it must have been removed before iteration started.

So, I am currently suspicious about the process of destroying an entity. Is the following scenario possible?

• Somewhere in the code I issue a destruction of an entity having an Instigator component
• While entity is being destroyed, Instigator is removed
• This triggers on_destroy, which now adds Collector tag to the entity in the middle of its destruction process.
• The destruction of an entity does not notice that Collector was added (is that possible?)
• entity is destroyed. But Collector storage still has an entry of that non-existent entity.

If that is so, do you have any suggestion how I could fix it on my end?

One way I see I could do it, is, instead of having a tag Collector, just keep my own unordered_set of entities, separate from the registry, and when i call func, check if entity is valid. However, I believe that managing a tag component and iterating over that tag component is probably much more efficient, as entt was designed to handle that kind of operation.

Other solution? In on_destroy I would have to detect that current entity is being destroyed entirely, but is it possible? I do have a tag Destroyed and perform the actual destruction in a separate system, but this will not help in this case, as Destroyed component may be removed early in the process of entity destruction.
Hm... maybe an inverse: IsAlive tag would be better?

[skypjack]

• This triggers on_destroy, which now adds Collector tag to the entity in the middle of its destruction process.
• The destruction of an entity does not notice that Collector was added (is that possible?)
• entity is destroyed. But Collector storage still has an entry of that non-existent entity.

The destruction of an entity expects that you don't add components to the same entity in a callback. The registry triggers an assert in debug mode if this happens, while it's UB in release.
So, well, yeah, this is definitely possible. 🙂

If that is so, do you have any suggestion how I could fix it on my end?

A quick and dirty solution is to replace the destroy with something like:

registry.remove_if_exists<Instigator>(entity);
registry.destroy(entity);

Otherwise, you can use a dedicate sparse set rather than a pool that is managed by the registry, then test if its entities are valid. This will filter out destroyed entities.
The next version should (will?) have entities put in a dedicate pool that you can query and use in views. You can so combine the Collector with the entity pool to achieve the same.

It would also help if you could describe what you're trying to do. Maybe someone can come up with a better suggestion. 👍

[LiliumAtratum]

Thank you for confirming my suspicions, and suggesting using the sparse set directly. I presume that if I use entt::basic_sparse_set<entt::entity> everything will work as intended and efficiently? I am a bit concerned that entt::entity value can become a high number, as it represents (ID + version), and high numbers can cause the sparse array within the sparse_set "explode" in memory. Or is my concern unwarranted?

As for what I am doing - I am creating a collector that reacts to any change of a given component. Before I noticed the problem it looked like this:

template<typename Instigator, typename Collector>
class OnChange {
  public:
    OnChange(entt::registry& registry) : registry_(registry) {
        registry_.on_construct<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();
        registry_.on_update<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();
        registry_.on_destroy<Instigator>().template connect<&entt::registry::emplace_or_replace<Collector>>();
    }

    ~OnChange() override {
        registry_.on_construct<Instigator>().template disconnect<&entt::registry::emplace_or_replace<Collector>>();
        registry_.on_update<Instigator>().template disconnect<&entt::registry::emplace_or_replace<Collector>>();
        registry_.on_destroy<Instigator>().template disconnect<&entt::registry::emplace_or_replace<Collector>>();
    }
	
    template<typename Func>
    void each(Func &&func) {
        registry_.view<Collector>().each([&](entt::entity entity) { func(registry_, entity); });
        registry_.clear<Collector>();
    }
  private:
	entt::registry& registry_;
};

And then I use it in my systems to define logic: if for given entity component A is changed (added, removed, updated), then recompute component B. For the sake of simplicity I assume that func itself does not change Instigator or Collector components as that could cause omissions.

[Innokentiy-Alaytsev]

While the numbers can grow high, the size of the array won't grow beyond 2^20 for 32-bit entities. The sparse array is also paged so you won't get memory allocated for all the unused entities. The packed array will be only as big as is required for storing the actual data, so after some saturation period, it will stop growing as well.

[LiliumAtratum]

Yeah, I was never concerned with the dense array, but the sparse - it won't know that it should use only the ID part (2^20) for indexing entt::entity. However, if there is paging as you say, it will help.

[skypjack]

I am a bit concerned that entt::entity value can become a high number, as it represents (ID + version), and high numbers can cause the sparse array within the sparse_set "explode" in memory. Or is my concern unwarranted?

it won't know that it should use only the ID part (2^20) for indexing entt::entity.

In fact, the version is kindly ignored by the sparse set and therefore by its sparse array, so this isn't a problem at all. Only the first N bits are used for indexing. In other words, an entity will always fall into the same page, not matter what its version is (that is stripped out). Moreover, yeah, the whole thing is also paged. I wouldn't worry about memory consumption of a collector to be honest.
Feel free to ask if you have any other question. 👍