Handle recursive race condition

This commit is contained in:
Ukendio 2025-12-21 20:30:55 +01:00
parent aa63051db3
commit e4d0fb447d

View file

@ -3119,13 +3119,12 @@ local function world_new()
in the opaque call stack. Essentially the entry is removed on a in the opaque call stack. Essentially the entry is removed on a
first come first serve basis. first come first serve basis.
The solution is to hold onto the borrowed references of the The solution is to separate processing from cleanup. We first iterate
archetypes in the lexical scope and make assumptions that the data over the archetypes to process entities (move them, call hooks, etc.),
itself is not invalidated until `archetype_destroy` is called on it. but do not destroy the archetypes yet. Then we iterate again to destroy
This is done since it is the only efficient way of doing it, however the archetypes, but check if they still exist (archetypes[archetype_id]
we must veer on the edge of incorrectness. This is mostly acceptable is not nil) before destroying. This handles the case where recursive
because it is not generally observable in the user-land but it has world_delete calls have already destroyed some archetypes.
caused subtle when something goes wrong.
- Marcus - Marcus
]] ]]
@ -3223,7 +3222,12 @@ local function world_new()
end end
end end
archetype_destroy(world, idr_t_archetype) end
for archetype_id in archetype_ids do
local idr_t_archetype = archetypes[archetype_id]
if idr_t_archetype then
archetype_destroy(world, idr_t_archetype)
end
end end
end end