Re: test-fdutimensat racy?

[Eric Blake]

On 05/21/2013 06:52 AM, Bernhard Voelker wrote:
>> 05/03/2013 10:37 AM, Bernhard Voelker wrote:
>> I.e., the numbers did not went significantly down for that non-VM system. ;-/
> 
> Playing with the code a bit and testing on various VMs (where the race
> showed up most probably), it turned out that the multiplier for the nap()
> delay is not sufficient.  Changing it from 1.125 to 3 seemed to make the
> tests quite stable.  However, avoiding the race completely would be much
> nicer.
> 
> What do you think about the following approach?

Interesting, but problematic on mingw:

>  /* Sleep long enough to notice a timestamp difference on the file
> -   system in the current directory.  Assumes that BASE is defined,
> -   and requires that the test module depends on nanosleep.  */
> +   system in the current directory.  Use an adaptive approach, trying
> +   to find the smallest delay which works on the current file system
> +   to make the timestamp difference appear.  Assert a maximum delay of
> +   2 seconds.  Assumes that BASE is defined, and requires that the test
> +   module depends on nanosleep.  */
>  static void
>  nap (void)
>  {
> -  static struct timespec delay;
> -  if (!delay.tv_sec && !delay.tv_nsec)
> +  static int fd = -1;
> +  struct stat old_st;
> +  static int delay = 1;
> +
> +  if (-1 == fd)
> +    {
> +      ASSERT ((fd = creat (BASE "naptmp", 0600)) != -1); /* Never closed.  */
> +      ASSERT (unlink (BASE "naptmp") == 0);

unlink() of an open fd is not guaranteed to succeed, and indeed fails on
mingw; you can also provoke the failure in some NFS setups.  You'd need
to add some cleanup (maybe an atexit hook will work) that closes and
only then removes the witness file.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature