Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-11-01 04:41:26

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/