On Mon, Mar 14, 2011 at 4:05 PM, Paolo Bonzini <bonz...@gnu.org> wrote: > On 03/14/2011 03:44 PM, Eric Blake wrote: >> >> > No, that's exactly the_wrong_ reason for TCP_NODELAY. You simply >> > cannot expect message boundaries to be respected when using >> > SOCK_STREAM. >> > >> > So, either sendfd/recvfd must be documented to work only on SOCK_DGRAM >> > sockets, or they have to be rethought (if possible at all). >> >> Note that just last week libvirt found an issue with SOCK_STREAM hanging >> forever on recvfd when the sendfd side was skipped, but SOCK_DGRAM was >> able to reliably detect when the sending side of the socket is closed. >> I'm perfectly fine with documenting that sendfd/recvfd must be used on >> SOCK_DGRAM only. > > But that was a different problem. That was not related to sendfd/recvfd. > > However, there are cases in which you want to send a file descriptor as > out-of-band messages on a stream socket, and libvirt also has one of those.
Does sending as oob data process id will fall on the previous trap on SOCK_STREAM ? oob are not implemented for unix so it will work under windows emulation Bastien > > From a quick experiment, BTW, on a SOCK_DGRAM Unix socket you don't need to > send fake data at the same time, but I may be wrong and/or that may not be > portable. > > Paolo >
