[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 16:19:31 +0100

On Mon, Mar 14, 2011 at 4:05 PM, Paolo Bonzini <address@hidden> 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
>> >
>> >  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

oob are not implemented for unix so it will work under windows emulation

> 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

reply via email to

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