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

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-08-12 05:41:54

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

> On Sun, Aug 11, 2013 at 4:24 AM, Rob Stewart <robertstewart_at_[hidden]>wrote:
> 
>> 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.

I wasn't advocating for API allocation, just allowing for it. Sometimes, the API knows how many bytes are needed to read the available data and the caller doesn't. To get the information to the caller, some APIs use a zero length buffer to signal the return of the needed length so the caller can allocate and call the API again. In those cases, it is simpler for the API to allocate. However, that also means the caller is responsible for releasing the memory. In those cases, I resort to returning std::auto_ptr (gasp!) (unique_ptr in C ++ 11). That, of course, forces free store allocation.

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

Creating two pipes gains full duplex.

> Plus the semantics of creation and destruction are slightly more similar for unix sockets and windows named pipes.

I can see how that would be desirable.

___
Rob

(Sent from my portable computation engine)