era replied to the list about:
On Wed, 5 Jan 2000 15:46:08 -0800, Benjamin Elijah Griffin
<bgriffin(_at_)cddb(_dot_)com> (ur'f onnnpx, sbyxf!) wrote:
> I need to have one recipe wait for a previous one to finish
> before it should run. (One saves output from a filter to a
> file, the next prepends that output to the message body.)
...
Like I said, this merely prevents anything else from creating the
lockfile until this fellow removes it again (with LOCKFILE= ). The
proper way to serialize two sequential processes is to have them both
use the same lock, something like
:0w:same.lock
| feller one
:0w:same.lock
| feller two
This will not let "feller two" start until "feller one" has finished.
(But you will still need the w flag, unless you merely want to prevent
them from +starting+ at more or less the same time.)
...
So you can get rid of the LOCKFILE business altogether (except if you
also want to prevent another copy of Procmail from entering this
critical section) and use local locks (and w flags) on the recipes
here.
This last part is critical. While two local lockfiles will serialize
the recipes with respect to the processing flow within one instance of
procmail, it does not prevent two separate instances of procmail from
stepping on one another. Process one, handling message one, can pipe
to feller one and then be swapped out. Meanwhile, procmail process two
handling message two can pipe to feller one and then go on to feller
two. When process one comes back and pipes to feller two, the state
may be very different as a result of process two. The chance of this
happening is small, but it increases with the volume of mail, and we
have recently seen such race conditions on the list. So, if there is a
temporary file not uniquely identified (perhaps by PID), you probably
want a global lock file as well as w flags.
--
Rik Kabel Old enough to be an adult
rik(_at_)netcom(_dot_)com