From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-10 16:37:49
> How did I review: browsed through the documentation. The most
> obviously missing thing is the ready-made support for LOCAL
> (also called UNIX domain) sockets, or named pipes on Win32.
> These are very useful and popular IPC mechanisms.
> I don't know whether Win32 supports LOCAL domain sockets,
I don't believe it does.
> and using Win32 style named pipes won't be portable (as UNIX
> named pipes are not bidirectional).
> This is not a request for implementation, but it would be nice
> if the author commented whether it is possible to support the
> following local IPC mechanisms within the library (with
> possible loss of functionality):
I believe all 4 are possible, with varying degrees of work.
> 1. anonymous UNIX pipes (pipe(2) system call)
This would require a new abstraction similar to the existing
basic_socket_stream (a basic_pipe if you will). Since pipes can
be used with select (or epoll or kqueue AFAIK) it should be
simple enough to implement the asynchronous operations for it.
> 2. anonymous UNIX sockets (socketpair(2))
Never used this function myself, but this looks pretty simple to
implement. For example (error handling omitted for brevity):
template <typename Protocol>
const Protocol& p,
socketpair(p.family(), p.type(), p.protocol(), d);
Then a protocol class, let's call it unix::stream, would have to
be defined. This would be similar to ipv4::tcp or ipv4::udp.
This also needs to be done for number 4 below.
To use this new function:
make_socket_pair(unix::stream(), s1, s2);
// Now use like any other sockets.
> 3. named UNIX pipes (created by e.g. mkfifo command) and WIn32
As with number 1, this would require a new abstraction, e.g. a
basic_named_pipe. As long as the descriptor returned by mkfifo
can be used with select (or epoll or kqueue) the asynchronous
operations can be implemented. For Win32, named pipes support
overlapped I/O, so they should be straightforward to integrate
The tricky part with this one is deciding the appropriate level
of abstraction for security (the mode passed to mkfifo or the
SECURITY_ATTRIBUTES passed to CreateNamedPipe).
> 4. LOCAL sockets
New classes for AF_UNIX would have to be defined. That is, the
equivalent of ipv4::tcp and ipv4::tcp::endpoint, perhaps called
unix::stream and unix::stream::endpoint. Once these are
available the existing socket classes can be used as-is. For
> I cannot give any recommendation since I didn't do a proper
> review. Overall, judging from the examples and the reference
> documentation, the library seems simple to use and extensible.
> Another plus is the header-only implementation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk