On Mon, Mar 14, 2011 at 3:44 PM, Eric Blake <ebl...@redhat.com> wrote: > On 03/14/2011 08:39 AM, Paolo Bonzini wrote: >> On 03/14/2011 03:02 PM, Bastien ROUCARIES wrote: >>>> > >>>> > recv(socket, buf, 512) => return 17, buf = "getfd\n0x12345678\0" >>>> > parse getfd >>>> > recvfd fails, or even worse it blocks (possibly forever) >>>> > even if recvfd doesn't block, parsing 0x12345678\0 fails >>> Why ? It is like sending and receiving data throught a protocol. i >>> will emulate AF_UNIX by tcp socket over localhost with TCP_NODELAY >> >> 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.
Will work for me Bastien
