ecs: a lookup through an index shouldn't conflict with a writer whose rows are exclusive to the index's

Ouverte
  • Quelque chose ne va pas ?
#254 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
data

Piste de recherche

Start from the scheduler's access-conflict check that #246 extended, the code that emits the message Systems ... both access ... and one writes it. The request is to treat a lookup through an index as carrying that index's components.with and not, so a writer whose not excludes the index's with no longer conflicts on the key. Read the reply on #246 first, since it sets which lookup kinds may skip the check. Done means a schedule with showHover and extrudeSelection builds without an ordering, and the non-unique and up cases keep their current behaviour or are explicitly excluded. The issue leaves soundness for non-unique and up lookups open, so settle that before writing code.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

A lookup through an index conflicts on its key with any system that writes that key, even when the writer's rows can never be in the index, because the index's own with/not is disjoint from the writer's. #246 made that disjointness count for two systems' rows (one requires a component the other's not lists); an index a system looks through carries the same information statically (its components.with / not) and isn't used.

Where this came from (mecs)

The editor draws a hover mark: an entity with [hovered, cell, face, faceColor] that follows the pointer. showHover moves it with commands.add(row.entity, cell, ...), so the mark's face is drawn one sync point later than the pointer. I'd like it to write row[cell] = ... directly so it moves in the frame the pointer does.

cell is also the key of voxelAt, the unique index of voxels (Index.create({ key: [cell], unique: true, components: { with: Voxel } })) that extrudeSelection and selectFace look up by. The mark is not a voxel (Voxel includes voxel; the mark has no voxel), so nothing showHover writes can ever appear in voxelAt. With 0.3.0 I added not: [voxel] to showHover's rows, which resolved its conflict with deriveCells (rows of with: Voxel), but the build still fails:

Systems "extrudeSelection" and "showHover" both access "cell" and one writes it; order them with before or after.

extrudeSelection only looks cell up through voxelAt, whose with is Voxel, and showHover's rows have not: [voxel]: the two sets are exclusive by construction.

What I need

Treat a lookup through an index as if its rows were the index's components (with, not) for the exclusivity check #246 added: a lookup of an index whose with includes a component the writer's not lists doesn't conflict with that writer on the index's key. (The issue's reply said "lookups, up, index and order keys still conflict"; I'm asking for the index case to follow the same rule when the index declares exclusivity, since a schedule is built without a world and the index's declaration is all it has.)

If it can't be sound for non-unique or up lookups, restricting it to indexes is enough: it is the case that hurts.

Cost of the workaround

Ordering the two systems (after) adds a tier boundary and a sync point to a frame that is otherwise idle (#245 measured about 0.1 µs each, now less), and the order is arbitrary between two systems that have nothing to do with each other.

Langage dominant
TypeScript
Étoiles
12
Forks
8
Merge moyen
9 h 2 min
PR mergées (30 j)
25

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de adobe/data

Toutes les issues de adobe/data

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.