Re: [PATCH 1/7] gnulib substrate for ns-resolution time stamps

[Paul Eggert]

On 07/01/11 10:39, Eli Zaretskii wrote:

> given that the Windows system clock is millisecond resolution anyway

Ah, sorry, I didn't know that.  That should simplify things.

> So all that needs to be done on Windows is scale the times in
> nanosecond units, i.e. multiply the current values by 1000.

Yes, that sounds right.  If Windows is currently scaling by 1000
to get microseconds, it can simply scale by 1000*1000 to get
nanoseconds.  This should work for both file time stamps and
for the pselect emulation.  E.g., Windows can emulate pselect the
same way it emulates select, except it multiplies by another 1000.

>> The Windows emulation for <time.h> will need to define struct
>> timespec, if it doesn't already.
> 
> Which functions require that, and why?

Any function that uses EMACS_TIME, because EMACS_TIME is now struct
timespec.  At the gnulib level (which doesn't use EMACS_TIME of
course), the functions involved include get_stat_mtime,
get_stat_atime, gettime, fdutimens, and pselect.

>> The Windows port should set high-resolution file time stamps.
> 
> For which primitives?  Note that copy-file already uses a
> Windows-specific API which takes care of copying the file time stamp
> correctly.

In that case, it should work the same way as before, and there's
no need to emulate utimensat or whatever.