I already implementing the workaround to use a file-based config after discovering the double-read. I think the test for S_ISREG seems appropriate (just don’t use lstat since you want to follow symlinks). > On Mar 18, 2018, at 4:05 PM, Greg Hudson via RT wrote: > > The profile library is designed to automatically pick up changes to > the profile each time a profile_get_* call is made. This feature is > of dubious usefulness, because our code base is inconsistent about > how long it caches profile results for, but I've been reluctant to > simplify it out. > > To do this, it calls stat() and compares the mtime to the mtime from > the previous stat() result. It does compare fractional timestamps, > so you would think the double-read would happen all the time (since > stat() on /dev/fd/NN appears to just give the current time). > However, there is also a guard against issuing too many stat() system > calls; at prof_file.c:316 we compare the current time to the last > time we read the filed or called stat(), and only issue a new stat() > call if the second has ticked over. > > So I think in your scenario a failure only happens if the second > ticks over between the initial profile open and the profile read to > get the stash filename. > > I think we could fix this scenario from our side by disabling the > stat-and-reread behavior for things that aren't regular files as > determined by S_ISREG(). From your side, you could of course work > around the issue by using a regular file.