Libelektra: mmap : environnement changeant

Vous avez raison, actuellement le cache ne vérifie que l'ENV dans les plugins kdbOpen. Il peut facilement être vérifié dynamiquement, mais cela invoque le résolveur et je soupçonne que cela a un certain impact sur les performances.

Edit : Sur une note latérale : la configuration est vérifiée pour l'horodatage exact (granularité nanosec), mais le problème existe toujours et est également vrai pour le résolveur par défaut .

Une solution de contournement pour exactement ce bogue serait que nous stockions également les noms de fichiers résolus dans le cache mmap. Mais en général, cela n'aiderait pas, nous aurions en quelque sorte besoin de capturer toutes les variables qui pourraient avoir une influence (ou d'éviter l'utilisation de toute variable d'environnement à l'intérieur de nos plugins, ce qui pourrait être la solution la plus élégante de toute façon).

Je n'ai pas pensé à ce scénario, mais en fait, nous stockons le nom de fichier résolu dans le cache mmap. Si le chemin change, cela produirait un échec de cache.

Néanmoins, si $HOME change alors qu'un handle KDB est ouvert, il ne déplacera pas le cache vers le nouveau home.

Je n'ai pas pensé à ce scénario, mais en fait, nous stockons le nom de fichier résolu dans le cache mmap. Si le chemin change, cela produirait un échec de cache.

Parfait! C'est de toute façon le cas le plus important. Afaik, nous n'avons actuellement pas de variables d'environnement, à l'exception des résolveurs. (Toutes les variables d'environnement n'ont cependant pas d'impact sur le nom du fichier. Par exemple, curlresolver utilise HTTP_PROXY.)

Néanmoins, si $HOME change alors qu'un handle KDB est ouvert, il ne déplacera pas le cache vers le nouveau home.

Ok mais c'est un vieux bug (#1433). Je vais donc fermer ce bogue car mmap ne semble pas aggraver la situation.