The 2019 Cologne meeting highlighted that multiple approaches and design philosophies to asyn-chronicity and i/o were beginning to ‘butt heads’ against one another. The 2019 Belfast meeting found unexpected committee support for the low level file i/o proposal [P1883] file_handle and mapped_file_handle, with much feedback being received that many would like to see a similar low level API treatment of non-file i/o. It was noted again during the second discussion of [P1750] A Proposal to Add Process Management to the C++ Standard Library that most of P1750 deals with i/o rather than processes, because nowhere else in the standard deals with the pipe i/o required to speak stdin, stdout and stderr to child processes.
Straight after the Belfast meeting I had an email discussion with all the major modern i/o players on WG21, during which I proposed building a consistent low level i/o API framework capable of solving everybody’s use cases, while also being compatible with Sender-Receiver, and specifically designed so a Networking TS implementation could be wholly constructed from it. If successful, we would have a path forwards via which all modern i/o in the future C++ standard could be made a consistent experience for C++ developers, whilst retaining flexibility of composure and genericity, but also with low level i/o’s strong guarantees of propagating the i/o determinism characteristics of the underlying platform.
Due to limits on free time, the prototype only implements pipe_handle. Due to surprise at the diÿculty of matching ASIO’s performance, which required several complete redesigns to achieve which were time-costly, by the time this paper was written the prototype only works on Microsoft Windows, and only in single threaded configuration. The recommendations made by this paper ought to be coloured appropriately.