On 9/24/07, Dallman Ross <dman(_at_)nomotek(_dot_)com> wrote:
k3rn wrote Monday, September 24, 2007 5:58 PM:
On Monday 24 September 2007 17:12:43 Dallman Ross wrote:
Apply the i-flag to your recipe.
YEAH !!!
It just works !
Thank you so much !
Can you explain me why there was an error ?
I'm trying to understand but I got no clue...
I'm no hardware guy so may not be the best person to
explain this, but I'll try.
Er, hardware? ;-)
My understanding of why is that while procmail, being the
brute-simple tool that it is, will gleefully follow your
directive and shunt your message to a pipe, it nevertheless
has no way of knowing what program or thing you have
placed to the right of that pipe.
So far, so good ...
IOW, procmail's job ends
when it sends the thing on to the pipe (unless you've
told it to wait for the exit status). How can procmail
know how long to hold the pipe open if there's no
feedback from the other side of the pipe?
Here you've gone astray.
I'm sure I've explained this previously on the list, but I can't seem
to find that message, so:
When unix (or linux, or any related OS) creates a pipe, the OS
allocates a chunk of memory to act as an I/O buffer between the ends
of the pipe. This gives the process on the "writing end" of the pipe
some space into which to send data even if there's nothing reading on
the other end yet. When the buffer fills up, the OS blocks the writer
(usually). Then when a reader comes along, it takes (some, maybe all,
of) the data out of the OS buffer and the OS unblocks the writer so it
can send some more.
This dates from the days before symmetric multiprocessing, when
computing was single-threaded and processes had to run one after
another in some kind of time-sharing fashion. The buffer space allows
the writer to make some progress, so then the reader can make some in
its turn, and then the writer again, back and forth. It's also a lot
more efficient than making all writers and readers agree on how much
data to transmit.
In any case, what happens if the buffer fills up? The writer will
block until someone reads. That's OK if no reader has started yet,
because one might eventually come along and consume the data.
However, with a simple pipe, once the last possible file handle on
each end has been closed, that end can never be opened again. If the
last (or only) possible reader is gone, the writer would block
forever. The OS can't allow that to happen.
So it holds it open for some nominal length of time
and then closes it.
It's actually the reader that closes the other end of the pipe. The
OS doesn't detect this until the buffer fills up, at which point it
sends a SIGPIPE signal to the writer to let it know that there is no
possibility of more data flowing through the pipe. Procmail catches
SIGPIPE and interprets it as an error condition; most other programs
simply exit.
If your message was long or things are moving kind of
sluggishly or whatever, you can easily have a situation
where the pipe closes before your program or script has
finished its independent action.
Almost; it's the other way around. The script has finished its
independent action before procmail has finished writing the message to
the pipe.
For messages that are "small enough" to fit entirely into the pipe's
I/O buffer, this situation is never detected and the recipe succeeds.
If the message is bigger than the buffer, though, and the reading
program doesn't read all of it, procmail gets the SIGPIPE error.
The recipe's i-flag says to procmail, "Dude: just hold
that baby open, will you?" So then your program has
time to operate.
The i-flag means "ignore any errors, including SIGPIPE, that happen
when writing to this pipe."
Oh, what about that "usually" blocks? Well, the writer (or reader)
can set a flag on the file descriptor representing the pipe to make it
"non-blocking" in which case the system-level write or read call
simply returns an error when the pipe is full (write) or empty (read)
and the process can go on about its business and try again later. But
most programs that read and write stdin/stdout do not bother with
setting non-blocking.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail