[RndTbl] strange race condition on file entries

Trevor Cordes trevor at tecnopolis.ca
Sat Feb 1 15:10:14 CST 2014


I'm running into a strange race condition, that appears to me to be a 
Linux bug of some sort.

I'm doing, perl pseudocode:

system "process-file outputfileprefix"
# does work and puts it in files named outputfileprefix-0, outputfileprefix-1, etc

sleep 1;
if (!<outputfileprefix-[0-9]*>) {
  warn "try #2\n";
  sleep 2;
  if (!<outputfileprefix-[0-9]*>) {
    warn "try #3\n";
    die;
  }
}

# do something on outputfile*

For those that don't know <> is perl's glob op, which simply returns an 
array of all the files matching the glob.  !<> is thus true if no files 
match the glob.

What is happening is that 10-30% of the time, I get a "try #2" output.  I 
haven't yet seen a try #3.  Of course, having those retries (and sleeps) 
in there at all should not be required: I had to add them as I was seeing 
this program blow up in unexpected ways.

process-file does not do anything async'ly, AFAIK.  The final thing it 
does, the output that I need, is use the GD library to write a png file.  
Only after that does process-file exit.  There are no threads or forks, 
unless GD is doing one, but even then the mini-program above should not 
return from system until all threads and (non-daemonized) forks are done.

It appears the problem is process-file writes and closes a file, returns, 
yet the directory entry doesn't become visible to the calling script for 0 
to 3 seconds!  I was under the impression that such UNIX OS actions were 
guaranteed to occur reliably in sequence!

Note, the fs I'm using is local and normal harddisk-based.  It is not on 
NFS or SMB, which of course could show such results.

Comments?  Ideas?


More information about the Roundtable mailing list