Libelektra: mmap: Umgebung im Wandel

Du hast Recht, der Cache prüft derzeit nur die ENV in den Plugins kdbOpen. Es kann leicht dynamisch überprüft werden, aber dies ruft den Resolver auf und ich vermute, dass dies einige Auswirkungen auf die Leistung hat.

Bearbeiten: Nebenbei bemerkt: Die Konfiguration wird auf den genauen Zeitstempel überprüft (Nanosec-Granularität), aber das Problem besteht weiterhin und gilt auch für den Standardresolver .

Ein Workaround für genau diesen Fehler wäre, dass wir die aufgelösten Dateinamen auch im mmap-Cache speichern. Aber im Allgemeinen würde es nicht helfen, wir müssten irgendwie alle Variablen erfassen, die Einfluss haben könnten (oder die Verwendung von Umgebungsvariablen in unseren Plugins vermeiden, was sowieso die elegantere Lösung wäre).

An dieses Szenario habe ich nicht gedacht, aber tatsächlich speichern wir den aufgelösten Dateinamen im mmap-Cache. Wenn sich der Pfad ändert, würde dies einen Cache-Miss erzeugen.

Wenn sich $HOME jedoch ändert, während ein KDB-Handle geöffnet ist, würde es den Cache nicht in das neue Home verlagern.

An dieses Szenario habe ich nicht gedacht, aber tatsächlich speichern wir den aufgelösten Dateinamen im mmap-Cache. Wenn sich der Pfad ändert, würde dies einen Cache-Miss erzeugen.

Perfekt! Dies ist sowieso der wichtigste Fall. Afaik haben wir derzeit keine Umgebungsvariablen außer den Resolvern. (Allerdings haben nicht alle Umgebungsvariablen tatsächlich einen Einfluss auf den Dateinamen. ZB verwendet curlresolver HTTP_PROXY.)

Wenn sich $HOME jedoch ändert, während ein KDB-Handle geöffnet ist, würde es den Cache nicht in das neue Home verlagern.

Ok, aber das ist ein alter Fehler (#1433). Daher werde ich diesen Fehler schließen, da mmap die Situation nicht verschlimmert.