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

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Geoff Shannon (geoffpshannon_at_[hidden])
Date: 2013-08-10 23:47:34

Lots of good feedback, thank you!

On Sat, Aug 10, 2013 at 6:55 PM, Rob Stewart <robertstewart_at_[hidden]>wrote:

> named_pipe_object is an odd name. Why "object"?
>
> For consistency with the interprocess library.  For instance creating a
shared memory object you write:

shared_memory_object shm;

I actually don't like it either,

> Construction with char const * attaches to an existing pipe, while with a
> std::string it creates a pipe? That's horrible. Those ctors should have the
> same behavior. Use an enumerated type argument to distinguish on behavior
> from the other or use the Named Constructor Idiom.
>
Thanks for the catch, but that's really just a "typo" of me editing one
piece of documentation and not the other.  They will definitely have the
same behaviour.

> "some" in read_some() and write_some() is not helpful.
>

This again was for consistency with the Boost.Asio convertion of
differentiating reads/writes that will block until the size is full, vs the
more low level construct of write-what-you-can/read-what-is-available.

How does read_some() know the size of the supplied buffer? You need a size
> argument (or buffer type discussed separately).
>
I definitely favour the buffer type instead of size argument.  It looks
like Boost.Asio already has a buffer
type<http://think-async.com/Asio/asio-1.4.8/doc/asio/reference/buffer.html>that
can be used to wrap builtin arrays, std::vector or boost::array.  It
seems useful enough that it would be worth the coupling to use it.  Also,
it seems like this functionality wants to live halfway between Asio and
Interprocess :)

I don't think named_pipe_server is needed. One creates or connects to a
> named pipe. A single class can handle both aspects, through different
> constructors.
>
I disagree, and here's why.  With a named pipe you can either act as a
server, and be prepared to accept multiple incoming connections or you can
be a client and connect to a "server."  With a separate "server" object
this is fairly natural I think:

named_pipe_server pipeserv("pipename");

for (;;) {
   named_pipe cli_conn = pipeserv.accept();

   // Do stuff with the new client
}

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).

There is definitely another use-case for a one-to-one connection.  That
would be a good candidate for an alternate factory function on named_pipe,
but I think the separate server object is still useful.

Also, here's the new version with your all's feedback incorporated.

-- Geoff

Nothing is ever easy.