[PATCH 2 of 2] util: drop statmtimesec

Yuya Nishihara yuya at tcha.org
Sun Nov 22 09:56:28 CST 2015


On Sat, 21 Nov 2015 17:53:01 -0800, Pierre-Yves David wrote:
> On 11/20/2015 04:38 AM, Yuya Nishihara wrote:
> > Matt already pointed out it. (I didn't read the commit message this morning,
> > sorry.)
> >
> > "This has some impact on our file cache validation code in that it lowers
> > timestamp resolution. But as we still have to deal with low-resolution
> > filesystems, we're not relying on this anyway."
> >
> > Well, it's true our file cache has a problem on HFS+ or ext3, but float mtime
> > can avoid problems on modern filesystems now. And we haven't come up with an
> > alternative solution yet.
> >
> > So, instead of disabling float timestamps globally, perhaps we can reimplement
> > osutil.stat() and lstat() and use them where integer timestamps are necessary.
> > I'll try it.
> 
> I'm leaning toward yuya opinion here. The Brian approach is simple and 
> effective. The only issue I'm aware of is its compatibility with older 
> version of the binary. I think it would be easy to work around that 
> limitation.

The other issue is that third-party extensions (read hgwatchman) are likely
to fake a stat_result object by namedtuple or similar type. It has different
indexes than stat_result.

Another workaround is to wrap a stat_result to make .st_mtime return an
integer timestamp. Assuming that we use osutil.listdir(stat=True) in hot loops,
this won't cause notable performance degradation.

  st = intstatresult(os.stat(f))
  st.st_mtime # => int

> The main reservation I've with the Matt series is that it regress 
> something that is suboptimal but we do not have a better alternative 
> ready anyway. It also change some python global state which is somewhat 
> scary.


More information about the Mercurial-devel mailing list