Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

grantm (164)

grantm
  (email not shown publicly)
http://www.mclean.net.nz/

Just a simple [cpan.org] guy, hacking Perl for fun and profit since way back in the last millenium. You may find me hanging around in the monestary [perlmonks.org].

What am I working on right now? Probably the Sprog project [sourceforge.net].

GnuPG key Fingerprint:
6CA8 2022 5006 70E9 2D66
AE3F 1AF1 A20A 4CC0 0851

Journal of grantm (164)

Thursday August 02, 2007
04:19 AM

Infinite Loop?

[ #33959 ]

Here's some behaviour that surprised me. I would expect this program to loop forever:

#!/usr/bin/perl

use strict;
use warnings;

my $file1 = './test_file_1';
my $file2 = './test_file_2';

my $count = 1;
while(1) {
    unlink($file1);                      # create first file
    open(FILE, ">$file1");
    close(FILE);

    my $t0 = (stat($file1))[9];          # wait
    while(time() <= $t0) {
        sleep 1;
    }
    my $t1 = time();

    unlink($file2);                      # create second file
    open(FILE, ">$file2");
    close(FILE);

    if((stat($file2))[9] <= (stat($file1))[9]) {
        die sprintf(
            "Timestamps: %u %u  t0: %u t1: %u\n",
            (stat($file2))[9], (stat($file1))[9], $t0, $t1
        );
    }
    printf("Loop count = %u\n", $count++);
}

Given that test_file_2 is not created until the system clock is greater than the modification time on test_file_1, I would expect that the die statement would never be reached. In fact, it fails for me on multiple systems after running for a small number of minutes.

My test systems are all running Linux, and using local filesystems. I have seen this sort of funky effect when using network filesystems, presumably due to clock drift between client and fileserver. I've also run into problems where updating a file on a local NTFS partition under Windows would either not update the time or would update it to have an earlier value.

This came up because Andreas Koenig did some extensive testing to highlight random failures in XML::Simple's text suite. Now that I know it's the test itself that's at fault I just need to make it a bit more robust.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I can reproduce the behaviour also on FreeBSD. In a FreeBSD mailing list [derkeiler.com] I found an explanation on the precision of time handling. The interesing part is:

    Another problem with file times is that they can be older than the time at which they are made, due to shortcuts in time_second and getnanotime(). E.g., if the current time is N.009999 seconds so that time(3) returns N, then time_second may be (N-1) seconds, so file times may be 1 second older than the time at which they were made if vfs.timestamp_precision is the default.

    This seems to be exactly the problem you had. In FreeBSD, there's the possibility to set the precision of filesystem timestamps to microseconds or nanoseconds (instead of just seconds). If I do so and re-run the script, then the problem does not occur, at least for 10000 iterations (formerly ~400 iterations were enough).