[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: passfd on more platforms

From: Bastien ROUCARIES
Subject: Re: passfd on more platforms
Date: Mon, 14 Mar 2011 15:55:15 +0100

On Mon, Mar 14, 2011 at 3:44 PM, Eric Blake <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]