On 1 Nov 2016 at 13:17, Gavin Lambert wrote:
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.
NT has a really well designed pipe (and i/o) implementation, much better than POSIX. It *definitely* can close a child's end of a pipe when the child suddenly exits if you configure it right. In any child process implementation I've ever written, this just works and is reliable.
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.
You also need to mark the pipe handle as non-inherited and handles are reference counted in the whole system. You can change an existing HANDLE to inherited or non-inherited whenever you feel like, include HANDLEs you don't own. You can also close handles in child processes for it incidentally.
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.
Anonymous pipes are simply named pipes with a random name. No difference. Process might wish to make use of NtCreateNamedPipeFile() in the NT kernel and using NtCreateFile to open the new pipe in the special pipe section of the NT kernel namespace. You don't get the win32 API in the way making pipes look confusing and hard, because they're not. The NT kernel API for pipes is really lovely, same as all the i/o NT kernel APIs, you'll find it all just works without being confusing. You also don't need to use completion ports like ASIO does for async i/o on Windows which are slightly complex to use. There is a much simpler solution called alertable i/o which AFIO v2 uses which has NT dispatch for you all pending async i/o callbacks every time you sleep a thread. Examine AFIO v2's source code for ideas if you like, you can throw together an async pipe i/o multiplexed reactor with very little effort in no time because NT has already implemented an "ASIO" for you, no ASIO needed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/