Eric Blake asked:
> > - to rewrite the test to use the 'execute' module instead of fork().
>
> Why do we even need a child process? Can't we test passing of an fd
> between two threads of the same process?
1) Because the typical use-case is passing file descriptors between different
process
Bastien ROUCARIES wrote:
> Could you apply the attached patch
>
> It is a little bit more paranoid, and could be good on strange platfor
Please, if you want me to apply a patch from now on, provide it with all
details correct (in particular GNU style code) and a ChangeLog entry.
In this patch, c
Bastien ROUCARIES wrote:
> according to postfix source NETBSD seems really strange... Do you know
> how to test ?
> /*
> * The CMSG_LEN send/receive workaround was originally developed for
> * OpenBSD 3.6 on SPARC64. After the workaround was verified to not break
> * Solaris 8 on SPA
On Mon, Mar 14, 2011 at 18:40, Bastien ROUCARIES
wrote:
> It is easy to have a workable send/recvfd with SOCK_STREAM under unix
> (except the close problem)
How so? You said that OOB is not supported by AF_UNIX stream sockets
(only TCP, which does not support SCM_RIGHTS of course)? And writing
On Mon, Mar 14, 2011 at 6:39 PM, Eric Blake wrote:
> On 03/14/2011 11:37 AM, Bastien ROUCARIES wrote:
>> On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini wrote:
>>> On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES
>>> wrote:
On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini wrote:
> On 03/1
On 03/14/2011 11:37 AM, Bastien ROUCARIES wrote:
> On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini wrote:
>> On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES
>> wrote:
>>> On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini wrote:
On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote:
>
> Not s
On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini wrote:
> On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES
> wrote:
>> On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini wrote:
>>> On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote:
Not sure BTW it will be really simple:
- send as oob data
On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES
wrote:
> On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini 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 i
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!
And BTW I will i
On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini 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 (sho
On Mon, Mar 14, 2011 at 4:50 PM, Paolo Bonzini wrote:
> On 03/14/2011 04:43 PM, Bastien ROUCARIES wrote:
>>>
>>> > While using TCP out-of-band data would be an interesting solution for
>>> > Windows, UDP doesn't have out-of-band data. So, if sendfd/recvfd is
>>> > going
>>> > to be limited to
On 03/14/2011 04:43 PM, Bastien ROUCARIES wrote:
> While using TCP out-of-band data would be an interesting solution for
> Windows, UDP doesn't have out-of-band data. So, if sendfd/recvfd is going
> to be limited to SOCK_DGRAM, using out-of-band data for Windows is not going
> to work.
Cou
On Mon, Mar 14, 2011 at 4:36 PM, Paolo Bonzini wrote:
> On 03/14/2011 04:19 PM, Bastien ROUCARIES wrote:
>>>
>>> > 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-
On 03/14/2011 04:19 PM, Bastien ROUCARIES wrote:
> 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
On Mon, Mar 14, 2011 at 4:05 PM, Paolo Bonzini 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
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 re
On Mon, Mar 14, 2011 at 3:44 PM, Eric Blake 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
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 doe
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
On Mon, Mar 14, 2011 at 2:45 PM, Paolo Bonzini wrote:
> On 03/14/2011 02:36 PM, Bastien ROUCARIES wrote:
>>
>> Or you could ask throught the socket, the process id of the receiving
>> process than send the handle.
>>
>> Remember:
>> It is assumed that the two sides have coordinated and agreed to
>
On 03/14/2011 02:36 PM, Bastien ROUCARIES wrote:
Or you could ask throught the socket, the process id of the receiving
process than send the handle.
Remember:
It is assumed that the two sides have coordinated and agreed to
transfer a file descriptor already, so that the sendfd is met with a
recv
On Mon, Mar 14, 2011 at 2:20 PM, Paolo Bonzini wrote:
> On 03/14/2011 12:38 AM, Bruno Haible wrote:
>>
>> On mingw, I haven't even tried the module. It first requires
>> - a 'socketpair' module for the test,
>> - to rewrite the test to use the 'execute' module instead of fork().
>
> MinGW woul
On 03/14/2011 12:38 AM, Bruno Haible wrote:
On mingw, I haven't even tried the module. It first requires
- a 'socketpair' module for the test,
- to rewrite the test to use the 'execute' module instead of fork().
MinGW would need a total rewrite. The Win32 API requires you to
duplicate t
On 03/13/2011 05:38 PM, Bruno Haible wrote:
>
> On mingw, I haven't even tried the module. It first requires
> - a 'socketpair' module for the test,
> - to rewrite the test to use the 'execute' module instead of fork().
Why do we even need a child process? Can't we test passing of an fd
betw
Could you apply the attached patch
It is a little bit more paranoid, and could be good on strange platform
>
> Bastien
>
diff
Description: Binary data
On Mon, Mar 14, 2011 at 12:38 AM, Bruno Haible wrote:
> Here's the result of testing passfd:
>
> Linux OK BSD4.4 way, MSG_CMSG_CLOEXEC
> FreeBSD OK BSD4.4 way
> OpenBSD OK BSD4.4 way
> NetBSD FAIL BSD4.4 way
> AIX OK BSD4.4 way
> HP-UX OK BSD4
Here's the result of testing passfd:
Linux OK BSD4.4 way, MSG_CMSG_CLOEXEC
FreeBSDOK BSD4.4 way
OpenBSDOK BSD4.4 way
NetBSD FAILBSD4.4 way
AIXOK BSD4.4 way
HP-UX OK BSD4.3 way
IRIX OK BSD4.3 way
OSF/1 OK BSD4.4 way
Sol
27 matches
Mail list logo
