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

[Paul Eggert]

On 07/01/11 04:20, Eli Zaretskii wrote:
> since we define our own struct stat, we can easily add to it
> the members supported by stat-time.h, define the appropriate macros,
> and that's all that's needed on Windows.

Yes, that should be enough to read the 100 ns-resolution file time
stamps on Windows.  It's probably simplest to define
STAT_TIMESPEC in config.h, and to emulate the corresponding
behavior in struct stat.

> Could you perhaps tell more about the changes, and what they
> should provide on Windows that we don't already have?

They let Emacs set file ns-resolution file stamps as well.
And get the time of day to ns resolution.  And set delays
to ns resolution.  There's one exception: I don't yet have interval
timers to ns resolution.  I plan to add that, but my assumption
is that this won't affect Windows because the Windows port
doesn't use setitimer anyway.

I just now reread the patch with an eye for possible porting
problems to Windows.  Here are some issues you may
want to think about.  (I don't know Windows, so I may well
have missed something.)

The Windows emulation for <time.h> will need to define struct
timespec, if it doesn't already.

The Windows port should set high-resolution file time stamps.
Perhaps the simplest would be to define HAVE_UTIMENSAT, and to define
a Windows emulation for POSIX utimensat, and then compile
lib/utimens.c.  The utimensat emulation can assume that the first
argument is always AT_FDCWD (which means the second arg
is just an ordinary file name), and that the last argument
is always zero (so symlinks are always followed).  The usual
style in utimensat emulators is to truncate file time stamps
to the greatest supported value that is not greater than the supplied time
(i.e., discard the last 2 digits of the nanosecond count when converting to
a 100-ns resolution).

Does Windows support a BSD-style nanotime () or POSIX-style
clock_gettime (CLOCK_REALTIME, x)?  If so, all you'd need to
do is to define HAVE_NANOTIME or HAVE_CLOCK_GETTIME in config.h,
and arrange to compile lib/gettime.c on Windows.  If not, you'll
also need to supply a substitute for either of those two functions;
probably nanotime () as it's simpler.

Does Windows support a POSIX-style pselect ()?  If not, it'd be
nice to add one.  It should act like select () except it uses
nanosecond-style time stamps.  Emacs doesn't use the sigmask argument
of pselect so the Windows emulation can ignore that.  Assuming that
Windows has a 100ns-resolution equivalent to select(), the pselect()
should take any delay, round it up to the nearest multiple of 100ns,
and use that multiple.  If the conversion to Windows time overflows,
I suggest using the maximum possible delay.  Alternatively, you
can simply compile lib/pselect.c, which will use the Windows select()
emulator: that'll cause the Windows port to delay up to
900 ns more than it otherwise would, but this is no big deal.

Does Windows have sys/select.h?  If not, the port can supply one,
with the appropriate declaration for pselect.

The Windows port will need to compile a few more files under lib/,
namely, dtotimespec.c, gettime.c, timespec-add.c, and
timespec-sub.c.  These should all be straightforward, assuming
the above problems are solved.