X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 22 Sep 2009 16:24:23 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Opening a socket connection in a fork ?
Message-ID: <20090922142423.GT20981@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <cef27f050909161316x1f38676bie677bbdeae0bf0c AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cef27f050909161316x1f38676bie677bbdeae0bf0c@mail.gmail.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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