[RndTbl] strange race condition on file entries

Dan Martin ummar143 at shaw.ca
Sat Feb 1 16:42:46 CST 2014


Very strange.  I try to stay away from perl, but it looks like you should never get “try #2”.

Both system and backquote should block until the process is finished, then return to the script.

Is it possible that the main perl process has a copy of the directory tree that is stale?
What would happen if you did system “ls” or something similar?

-Dan

On Feb 1, 2014, at 3:10 PM, Trevor Cordes <trevor at tecnopolis.ca> wrote:

> 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?
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable

Dan Martin
GP Hospital Practitioner
Computer Scientist
ummar143 at shaw.ca
(204) 831-1746
answering machine always on




More information about the Roundtable mailing list