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

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-31 20:17:53

On 1/11/2016 13:00, Klemens Morgenstern wrote:
> Not if you have a named pipe, that's the problem here. It could of
> course be that I missed something, but as far as I tested, you won't
> have a guaranteed close there.

It should; they're still just handles after all.  The pipe server itself 
is multi-use but the individual read/write pipe handles aren't.

Note that async_pipe has the same move-constructor bug that basic_pipe 
does (and that I made a PR for).  Perhaps that's the reason that you had 
the issue, since if you ever move-constructed it you'd leave a dangling 
unclosed handle.

> Well as for the first: I don't know if it's parent-only in the function,
> since forwarding is possible. For the second: yes I could assume that a
> pipe will not be reused and close the half, but that wouldn't do
> anything for the problem at hand as explained above.

If you're creating the pipes yourself for the express purpose of 
communicating with the child, then it should be well-defined which end 
of the pipe each process will be using, and you should be able to ensure 
that only one end is open in each process.

> It does not support that, you'll get an exception if you try it. THAT is
> the main problem. In order to make it asynchronous, you need the
> overlapped stuff, and you cannot do that with anonymous pipes. That is
> the main reason this doesn't work, becaues I have to assume that any
> given pipe may be a named one.

True, I forgot about the overlapped I/O issue.  That does complicate 
things, but as long as you use a guaranteed-unique name then you should 
be able to get equivalent behaviour.