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 pipes afaik.
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 name.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost