Libelektra: mmap: ambiente em mudança

Você está certo, atualmente o cache só verifica o ENV nos plugins kdbOpen. Ele pode ser facilmente verificado dinamicamente, mas isso invoca o resolvedor e suspeito que tenha algum impacto no desempenho.

Edit: Em uma nota lateral: a configuração é verificada para o carimbo de data / hora exato (granularidade de nanosec), mas o problema ainda existe e é verdadeiro para o resolvedor padrão também.

Uma solução alternativa para esse bug seria que também armazenamos os nomes de arquivos resolvidos no cache do mmap. Mas em geral não ajudaria, precisaríamos de alguma forma capturar todas as variáveis ​​que pudessem ter influência (ou evitar o uso de qualquer variável de ambiente dentro de nossos plug-ins, o que poderia ser a solução mais elegante de qualquer maneira).

Não pensei sobre esse cenário, mas na verdade armazenamos o nome do arquivo resolvido no cache do mmap. Se o caminho mudar, isso produzirá uma falha no cache.

Ainda assim, se $ HOME muda enquanto um identificador KDB está aberto, ele não realoca o cache para a nova casa.

Não pensei sobre esse cenário, mas na verdade armazenamos o nome do arquivo resolvido no cache do mmap. Se o caminho mudar, isso produzirá uma falha no cache.

Perfeito! De qualquer maneira, este é o caso mais importante. Afaik, atualmente não temos variáveis ​​de ambiente, exceto para os resolvedores. (Nem todas as variáveis ​​de ambiente têm realmente um impacto no nome do arquivo. Por exemplo, curlresolver usa HTTP_PROXY.)

Ainda assim, se $ HOME muda enquanto um identificador KDB está aberto, ele não realoca o cache para a nova casa.

Ok, mas este é um bug antigo (# 1433). Portanto, fecharei este bug, pois o mmap parece não piorar a situação.