Re: [boost] [Interprocess] Named pipe interface proposal

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Geoff Shannon (geoffpshannon_at_[hidden])
Date: 2013-08-11 20:20:06

On Sun, Aug 11, 2013 at 4:24 AM, Rob Stewart <robertstewart_at_[hidden]>wrote:

> How many other libraries will you try to be consistent with? Seriously,
> precedent can be good, but you can get carried away. Will you offer
> blocking and non-blocking read/write calls? If not, I see no advantage to
> "some".
>

For the most part the consistency idea came from deriving a place to start
from.  It was a helpful thing to do but your point is well taken.

> IIRC, that class doesn't manage any memory. It's just an adapter for
> various forms of buffers. There's still room for something like I mentioned
> in my other mail, especially if the API allocates on the caller's behalf.
>

I don't think the API should allocate on the caller's behalf.  Hence the
adaptor buffer seems like a good fit because it allows the user to use
whatever is natural for their application.  If you have a good reason for
thinking that it should I'd like to hear it.

Perhaps you're thinking differently than I. On Linux, for example, creating
> a named pipe (FIFO) means calling mkfifo() followed by two calls to open(),
> all using the same pathname....
>
> I presume your server ctor would call mkfifo() and accept() would call
> open(). How does accept() wait for a connection? Are you implying some
> underlying IPC for the client process to send notification of its desire to
> connect?
>
>

On Sat, Aug 10, 2013 at 3:41 PM, Geoff Shannon <geoffpshannon_at_[hidden]>wrote:

> For the unix side I've determined that the most compatible (feature and
> semantics-wise) mechanism would be Unix domain sockets.
>

I'm not going to be using mkfifo.  It's not full duplex, where unix domain
sockets are.  Plus the semantics of creation and destruction are slightly
more similar for unix sockets and windows named pipes.

> > Whereas if you had to use named_pipe for everything there's the
> potential for changing the name, and thus creating a completely new pipe
> (instead of
> > another connection on it).
>
> I don't see it. If the create + open and open only constructors are
> distinct, there's no more protection in separate class names. Use the Named
> Constructor Idiom for more clarity if you like.
>

This was a specious argument on my part, though it seemed real to me at the
time.  As mentioned in my other email I'll be pursuing this change in
interface.

-- Geoff

Nothing is ever easy.