Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-31 20:34:37
Am 01.11.2016 um 01:17 schrieb Gavin Lambert:
> 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.
Not sure there, I don't think that's entirely correct. At least from
what I tested. The closing of one side only does only work for anonymous
> 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.
Thanks, just fixed that. I don't think that's the reason I had the same
issue with process 0.5.
>> 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.
No, I am not. Since you have streams, they must have a handle so I need
to be able to duplicate pipes. Hence I could just close a duplicate,
which doesn't do a thing to help with the problem.
I really looked for a consistent solution, but sadly I didn't find one.
That's why I invested so much effort in making the asio-interface easy.
It could of course be that I missed something, but I didn't find a
solution that would be the same for the user on windows as on linux.
>> 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.
That's what's happening if you use a named pipe, it will create a unique
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk