Libelektra: mmap: entorno cambiante

Tienes razón, actualmente el caché solo verifica el ENV en los complementos kdbOpen. Se puede verificar fácilmente de forma dinámica, pero esto invoca al resolutor y sospecho que tiene bastante impacto en el rendimiento.

Editar: En una nota al margen: se verifica la configuración para la marca de tiempo exacta (granularidad nanosec), pero el problema aún existe y también es cierto para el solucionador predeterminado .

Una solución para exactamente este error sería que también almacenamos los nombres de los archivos resueltos dentro de la caché de mmap. Pero en general no ayudaría, de alguna manera necesitaríamos capturar todas las variables que podrían tener influencia (o evitar el uso de cualquier variable de entorno dentro de nuestros complementos, que podría ser la solución más elegante de todos modos).

No pensé en este escenario, pero en realidad almacenamos el nombre de archivo resuelto dentro de la caché mmap. Si la ruta cambia, se produciría un error de caché.

Aún así, si $ HOME cambia mientras un identificador KDB está abierto, no reubicará el caché en el nuevo hogar.

No pensé en este escenario, pero en realidad almacenamos el nombre de archivo resuelto dentro de la caché mmap. Si la ruta cambia, se produciría un error de caché.

¡Perfecto! Este es el caso más importante de todos modos. Afaik, actualmente no tenemos variables de entorno a excepción de los resolutores. (Sin embargo, no todas las variables de entorno tienen un impacto en el nombre del archivo. Por ejemplo, curlresolver usa HTTP_PROXY).

Aún así, si $ HOME cambia mientras un identificador KDB está abierto, no reubicará el caché en el nuevo hogar.

Ok, pero este es un error antiguo (# 1433). Así que cerraré este error ya que mmap parece no empeorar la situación.