| Subject: | profile_init may not always reflect profile changes due to g_shared_trees |
The profile library remembers a timestamp for each prf_data_t object;
these objects are in-memory representations of the contents of a
profile file. On open or get operations, it re-stats the file (up to
once per second for get operations). If the stat timestamp doesn't
match the remembered timestamp, the in-memory copy of the profile is
discarded and the profile is re-read.
The profile library also maintains a global table called
g_shared_trees which maps filenames to prf_data_t objects. When a
file is opened, if there is an existing mapping in g_shared_trees for
the filename, that in-memory copy is used. Therefore, the
consistency guarantees for open operations are only as good as the
ones for get operations (although we do make sure to always re-stat
the file).
Unfortunately, these consistency guarantees are imperfect in the face
of newer profile features. If the profile uses "include" or
"includedir", we do not remember the timestamps of the subsidiary
files. If the profile path is a directory rather than a file (new in
1.14), we check the timestamp of the directory but not the files
within it.
Fixing this problem seems to require a much more complicated notion
of timestamp, capturing all of the paths which were included. For
directories, we could remember the maximum timestamp of all of the
files in the directory.
Alternatively, we could try to do away with g_shared_trees and with
re-reading profiles on get operations, but there are complications
with each of those changes.
these objects are in-memory representations of the contents of a
profile file. On open or get operations, it re-stats the file (up to
once per second for get operations). If the stat timestamp doesn't
match the remembered timestamp, the in-memory copy of the profile is
discarded and the profile is re-read.
The profile library also maintains a global table called
g_shared_trees which maps filenames to prf_data_t objects. When a
file is opened, if there is an existing mapping in g_shared_trees for
the filename, that in-memory copy is used. Therefore, the
consistency guarantees for open operations are only as good as the
ones for get operations (although we do make sure to always re-stat
the file).
Unfortunately, these consistency guarantees are imperfect in the face
of newer profile features. If the profile uses "include" or
"includedir", we do not remember the timestamps of the subsidiary
files. If the profile path is a directory rather than a file (new in
1.14), we check the timestamp of the directory but not the files
within it.
Fixing this problem seems to require a much more complicated notion
of timestamp, capturing all of the paths which were included. For
directories, we could remember the maximum timestamp of all of the
files in the directory.
Alternatively, we could try to do away with g_shared_trees and with
re-reading profiles on get operations, but there are complications
with each of those changes.