Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-11-02 04:57:51

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/