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

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-08-11 07:24:56

On Aug 10, 2013, at 11:47 PM, Geoff Shannon <geoffpshannon_at_[hidden]> wrote:

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

Consistency is good, but not when carried too far. You intend this code to be part of Interprocess, so consistency with that library is good, when sensible. I don't think shared_memory_object is an appropriate class name, so copying it perpetuates the fault, IMO.

> For instance creating a shared memory object you write:
> 
> shared_memory_object shm;
> 
> I actually don't like it either,

Even if you keep your server class, the connection manager type doesn't need "object" in its name to distinguish it.

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

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

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

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

>  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
> }

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?

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

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

I don't understand your server idea.

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

Much improved.

FYI, "setup" is a noun, not a verb, so "open and setup" should be "open and set up".

___
Rob

(Sent from my portable computation engine)