[...] > Isn't this what putmsg() and getmsg() are for? Good one - I forgot about those. Problems with that: * still can't putmsg() more than PIPE_BUF (5120) bytes at once, at least not to a pipe (seem to be ok sending something larger to e.g. a pty). * you have to use poll(2) to check for POLLHUP after each getmsg() to distinguish a zero-length message having been received from EOF.
(I wrote a couple of programs that respectively use putmsg() on fd 1 and getmsg() on fd 0, and played with them given different size messages and trying to figure out a simple way to detect EOF.) I wonder if the semantics of an AF_UNIX socketpair() with sendmsg() and recvmsg() are nicer...at least one should be able to set the size of buffering using SO_SNDBUF and SO_RCVBUF. But using them as a substitute for pipes is ok only as long as you don't inherit a real pipe, nor force anyone that expects a real pipe to use those instead. (That is, I could write a simple LD_PRELOADable substitute for pipe() in terms of socketpair(), but I wonder what apps would not behave nicely with it, and contrariwise, I'm pretty sure that code written to use sendmsg() and recvmsg() would barf if handed a pipe.) (BTW, I think the current division of labor between libsocket and the kernel for socketpair() would cause some sort of failure with a SOCK_STREAM when one had only two free file descriptors. Not to mention that _if_ the whole thing were done in the kernel (which could avoid that problem) and _if_ there are no system apps that require pipe() to supply STREAMS pipes, it would be pretty easy to write a misc module that if one chose to load it, could change the semantic of pipe() from STREAMS to sockets systemwide.) -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
