Clear questions and runnable code
get the best and fastest answer
Re^3: avoiding a race ("No extra", "no-user" locking--miniscule race of no importance)by BrowserUk (Pope)
|on Sep 28, 2010 at 17:28 UTC||Need Help??|
That is not a non-locking mechanism. It just hands off the locking to the kernel which locks the directory when it reads from it or writes to it. It has the advantage of the kernel locking implementation being very well tested.
The kernel is going to do it's locking whatever file operations you do. Re-using it is good.
So, I guess you could call it a "no-extra, no-effort(or risk of getting it wrong)" locking mechanism.
Of course, errors might not all have such nice, unique, numeric identifiers ...
If you can't reduce the errors to something easily comparible in the filesystem, you'll have similar problems locating similar errors in the file itself. And globbing is capable of much more that just "string equality".
But, most importantly, your solution (as described) has a race condition between stat and creating a file. You can probably fix that a couple of different ways.
If I knew how to do open(CREATE_NEW(*)) in Perl, I would suggest that. If the open() fails, it must have 'just' been created, so there's nothing else to do, so you just move on anyway.
Update: The "race condition", whether this process creates a new file; or some other process does it for you a few milliseconds before you do, doesn't trigger extra emails.
Nor does it delay their being sent at the appropriate time. the time window is probably less than the resolution of the file system timestamps. So. NO race condition!
Very simple. Very effective. Perfection is the enemy of "good enough".
(*)Ie. Create a new file; fail if it already exists.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.