Author: Jeremy Harris Date: To: exim-users Subject: Re: [exim] Exim 4.88(9): failed to read pipe from transport
On 22/06/17 05:22, Kurt Jaeger wrote: > What stops us to read/write in chunks smaller than 512 bytes from/to
> that pipe ?
Posix specifies that writes of under some specific size (defined by the
implementation and available as a C #define for compilation time) are
atomic - meaning that a write of up to that size won't get get split
by an intervening write into the same pipe. It does not, as far as
I understand, say anything about _reads_ from the pipe getting either
the whole pipe content or the full data from such a max-size write.
FreeBSD's defined size here is 512 (and I think that's the smallest
permitted by Posix). Linux is somewhat larger.
The Exim coding assumes that the pipe reader can and will get the
entire result record from the transport process in one read (ie
both write and read behaviour is assumed).
With time, feature additions have resulted in the bloating of the
result record. Most particularly, the delivery peer TLS certificate
is now passed back (for logging purposes); as might be imagined this
can easily be kilobyte sized.
> Do we need the writes to be atomic to preserve msg boundaries or such ?
Currently the coding assumes that. Putting in a loop to read the full
expected record is obvious - but we will need to think very carefully
about running multiple concurrent transport processes, or restricting
the logging info, on systems with a small PIPE_SIZE.
The first would be a performance limitation, the second would be a
features limitation.
--
Cheers,
Jeremy