Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: profile_init may not always reflect profile changes due to
 g_shared_trees
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1536

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.