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?