https://bugs.exim.org/show_bug.cgi?id=2130
--- Comment #1 from Jeremy Harris <jgh146exb@???> ---
]from the mailing-list]
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.
The basic issue is that we want to know the full result record from one of
possibly-many transport procs is identifiable by the transport dispatch
process.
Query: do we create a new pipe for each transport proc? If so then a read loop
will suffice (but sharing one would be a performance enhancement).
We could also
- consider moving to a mechanism with nicer semantics, eg. a Unix-domain
socket.
SOCK_DGRAM would do if the max size is enough.
- add explicit checking vs. PIPE_SIZE in the transport proc, at time of result
record creation. Possibly, replace the peer-cert info with a placeholder
rather than just panicing. But also check the entire record size; cert info
is not the only problem cause.
- investigate the consumers of the peer cert info. Could we add a bit to the
address record requesting it only when needed? This would be a perf benefit
also on Linux, avoiding conversion and copy costs.
--
You are receiving this mail because:
You are on the CC list for the bug.
