[RndTbl] strange race condition on file entries

[Robert Keizer]

I would write a small test case in bash. Not hating on perl, but if it also
exhibits those symptoms, rules perl out completely.

Also post bash script if you do end up doing this -I wouldn't mind taking a
stab at it.

What file system are you using?

You could run strace on process-file which should tell you if it is indeed
doing something funny..

My guess is perl specific; I'd test without it and replicate.

Rob
On 2014-02-01 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20140201/4328234e/attachment.html>