procmail
[Top] [All Lists]

Re: holy benchmarks, Batman - resolution

2003-04-02 03:06:37
Mike Peeler <zconcept(_at_)panix(_dot_)com> writes:

Jeff Orrok <jeff(_at_)rt(_dot_)com> wrote:

Ah, the joys of sheer stupidity.

I don't necessarily succeed, but I try not to go around calling things
stupid unless I'm pretty sure who's on top, me or it.

Well, you certainly didn't succeed at comprehending that I was calling my
own actions stupid.

Well, I don't think you'd have brought this behavior to our attention,
had you not felt that procmail/lockfile was doing something wrong.  On
the other hand, simple mistakes often lead to interesting discoveries.


Procmail's internal lockit() function (not lockfile) creates a temp in
its usual safe way, and renames this temp to be the desired lock-file.
The tempfile couldn't be created, so lockit() waits locksleep seconds,
and tries again, for a total of nfsTRY (eight) times.  The unique-name
generator intentionally rotates one character of the filename from one
try to the next, in hopes of finding an empty slot in the hash bucket.
The observed behavior was not the result of any inadvertent data space
corruption, nor is it a design flaw.

If you say so.  Since ".nixon.xkey.com" has nothing to do with the name
of the lockfile, I thought that it was overwriting some other part of
memory.  And still, there is no point in retrying something that
destined to fail: creating files in non-existent directories.

For your information, procmail's unique tempfile name-generator begins
with something like a base-64 encoding of the time and its process ID.
It combines them in the form _pid.time.hostname, with the idea that at
a given time, there can only be one process with a particular pid on a
particular host.  But just in case, it rotates the first dot to comma,
plus sign, percent sign, and back to dot.  A tempfile is useful, here,
to take advantage of the atomic hard-link operation.  Simply opening a
file with the create-flag doesn't guarantee it wasn't someone else who
managed to create it at about the same time.  It's important that only
one of the two thinks it got the lock, while the other thinks it lost.

As I said, retrying a lock eight times, no more often than every eight
seconds, is a fairly cheap thing to do.  This operation is designed to
succeed, not to fail.  Actively investigating the possible reasons the
tempfile might have failed would actually be more costly to do, as in,
opening the directory.  If that wasn't the problem, that would've been
wasted effort.  A waste of precious CPU, when the commonest errors are
transient conditions for which the remedy is wait and try again later.

Mike


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>