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