https://bugs.exim.org/show_bug.cgi?id=2130
--- Comment #1 from Jeremy Harris <[email protected]> --- ]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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
