Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at