Re: passfd on more platforms

[Bastien ROUCARIES]

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
>> > 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
>