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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 01 Jul 2011 09:27:01 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> > 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.

Yes, I understand the motivation.  But given that the Windows system
clock is millisecond resolution anyway, we cannot really take
advantage of that, can we?  So all that needs to be done on Windows is
scale the times in nanosecond units, i.e. multiply the current values
by 1000.  The rest of the complexity is not really useful, right?

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

Which functions require that, and why?

> 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.

> Does Windows support a BSD-style nanotime () or POSIX-style
> clock_gettime (CLOCK_REALTIME, x)?

No.  We can write their emulations, but again: given the 1 to 10
millisecond resolution of the Windows system clock, why is that a good
idea?  Just taking the result of gettimeofday and multiplying the
microseconds by 1000 will give us the same result for much less
effort.

> Does Windows support a POSIX-style pselect ()?

No.  Again, since the time resolution is milliseconds, there's no real
difference between pselect and select, apart of the signature.  We
will not be able to wait less than 1 millisecond.

> Alternatively, you can simply compile lib/pselect.c, which will use
> the Windows select() emulator

I don't think this will work.  Emacs uses its own emulation of
`select'; replacing it with gnulib's will not work out of the box.