On 1 Nov 2016 at 23:57, Klemens Morgenstern wrote:
Am 01.11.2016 um 23:48 schrieb Gavin Lambert:
On 1/11/2016 21:41, Niall Douglas wrote:
You also don't need to use completion ports like ASIO does for async i/o on Windows which are slightly complex to use. There is a much simpler solution called alertable i/o which AFIO v2 uses which has NT dispatch for you all pending async i/o callbacks every time you sleep a thread. Examine AFIO v2's source code for ideas if you like, you can throw together an async pipe i/o multiplexed reactor with very little effort in no time because NT has already implemented an "ASIO" for you, no ASIO needed.
Having written my own mostly-lock-free ASIO-lite based around completion ports, I can confirm that they're not at all complex to use. Meanwhile I shy away from alertable I/O because it's thread-affine and requires remembering to always perform alertable waits, both of which seem fragile to me. Still, the advantage of both methods existing is that you can use whatever you feel most comfortable with. :)
I guess the right approach for boost.process would be, to add support for boost.afio when it comes out, as it does now for boost.asio. Elsewise you'd just have multiple libraries doing the same thing.
AFIO should land in the peer review queue in 2019. Outcome, upon which AFIO v2 is very heavily based (and probably would be the most contentious part of AFIO v2's API design), should land in the peer review queue early 2017 (I'm currently writing its tutorial at https://ned14.github.io/boost.outcome/). AFIO v2 was designed to understand child process handles and pipes, and its hierarchy of class inheritances allows easy extension to implement child process i/o support. Pull requests for that are welcome. BTW it is the lack of user supplied i/o backends in Process which was a big part of why I voted to reject it. The correct API design would allow the user to supply *any* implementation of child process i/o, and Process would not need to care what it is nor how it works. You would of course supply a default i/o backend probably based on popen() on POSIX or something equally simple, but the point is that you having to hard code support for ASIO or AFIO shows how Process has the wrong API design. My other big showstopper issue was you imposing on users your serialisation API i.e. all that iostreams and FILE * machinery. It's widely known that the committee would like a v2 iostreams to happen as soon as possible as the current iostreams is so very 1992. Quite a few people are experimenting with some very alternative designs right now, again if Process didn't need to be hardcoded to use some serialisation framework that would be a huge gain and in my mind the correct API design. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/