On Mon, Mar 14, 2011 at 6:39 PM, Eric Blake <ebl...@redhat.com> wrote: > On 03/14/2011 11:37 AM, Bastien ROUCARIES wrote: >> On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini <bonz...@gnu.org> wrote: >>> On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES >>> <roucaries.bast...@gmail.com> wrote: >>>> On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini <bonz...@gnu.org> wrote: >>>>> On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote: >>>>>> >>>>>> Not sure BTW it will be really simple: >>>>>> - send as oob data if fail with WSAEOPNOTSUPP come back to normal send >>>>> >>>>> But it will _always_ fail if people are using sendfd/recvfd as we (should) >>>>> document it, i.e. on SOCK_DGRAM sockets! >>>> >>>> Yes and if it fail we will fall back to the normal send, so no fail >>> >>> So why try in the first place?!? >> >> In order to have a working solution for SOCK_STREAM > > I'm confused. > > If we document that sendfd/recvfd only work for SOCK_DGRAM, then why do > you want to support SOCK_STREAM? That is, if we are going to document > the limitation, then why are you talking about working around the > limitation?
It is easy to have a workable send/recvfd with SOCK_STREAM under unix (except the close problem), so I will implement under windows for SOCK_STREAM > > -- > Eric Blake ebl...@redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > >
