This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Opening a socket connection in a fork ?


On Sep 16 22:16, Gu1ll4um3r0m41n wrote:
> Hello,
> I'm trying to run a program on cygwin that forks, opens a socket
> connection and sends the status of the connection to the parent
> process using pipes. The parent process then sends data through the
> opened socket.
> The program works well on linux but on cygwin, i cannot use recv on a
> socket opened in a fork. The recv function always return -1, errno 22
> ("EINVAL").
> The weird thing is that the socket stays open and send still works...
> 
> I attached a short example.
> I don't know if this is a bug or a limitation due to the fork()
> implementation in cygwin... I searched on google but couldn't find
> anything really useful.

It looks like a really weird problem in WinSock.  Cygwin doesn't do
anything special in this case.

The socket handle gets duplicated into the child process on fork.  The
child calls connect on the duplicated socket handle which apparently
succeeds.

In this scenario, calls to WinSock's recvfrom and WSARecvFrom in the
parent will fail with WSAEINVAL, regardless whether both address
parameters, name and namelen, are NULL or point to valid storage.
However, calls to recv and WSARecv succeed as expected.

Per MSDN, WSAEINVAL in the context of recv means  "The socket has not
been bound".  It is as if the recvfrom functions test if the socket is
bound locally, but in the parent process, WinSock doesn't know about
that and fails, while the same test is omitted in the recv functions.

The same problem does not exist for sendto/WSASendTo apparently.

I'm going to apply a patch which calls WSARecv rather than WSARecvFrom
if the name parameter is NULL.  This fixes the above problem and, given
that the `!wsamsg->name' check has to be called anyway to workaround
another WinSock problem, has no performance hit.

I also created a native Win32 testcase which proves that this isn't a
Cygwin problem, but a WinSock problem.


Thanks for the report,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]