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:09:14

On Sun, Aug 11, 2013 at 6:46 AM, Edward Diener <eldiener_at_[hidden]>wrote:

> OK, but you still need an explanation of how the end-user should use your
> named pipe functionality to do asio with each member function in your class
> where asio is possible. Using asio with named pipes in Windows involves
> making a connection, accepting a connection, sending data, and receiving
> data. In other words using asio with named pipes means never waiting on
> anything, but checking periodically if some operation has completed and
> doing other things if it has not.
>

I'll keep that in mind.  For now I'm going to completely punt on asio
behavior.

Glad to give it, but you don't have much code yet on which to comment.
>

I was speaking more in the abstract.  I'll be sure to let you know when
I've actually got an attempt at the Windows implementation.

> I would suggest you keep things really, really simple in your main
> interface. There should be the creation of a named pipe, listening for and
> accepting a connection, making a connection, reading data, and writing data.
>
> I think you should also consider your named pipe being outside of
> Boost.ASIO rather than as part of it, mainly because named pipes can be
> synchronous if the user wants to wait, let's say in some background thread,
> for operations to complete.

This is an excellent point.  I think I was getting a little focused on Asio
because it seems like a good idea, but I really know next to nothing about
it so there's no point in trying to implement it in the first pass.

On Sun, Aug 11, 2013 at 6:55 AM, Edward Diener <eldiener_at_[hidden]>wrote:

> I heartily agree with this last comment. KISS. There's no need for two
> different classes. A single named pipe class should be able to handle
> creation of a named pipe, listening for and accepting a connection, making
> a connection, reading data, and writing data. It really is that simple at
> the basic level.
>

Fair enough.  Since both you and Rob seem to be clear on that I'll pursue
that approach.

-- Geoff

Nothing is ever easy.