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.