Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Message-ID: <007f01c21348$72149600$5a6d3850@piggy>
From: "Roderick Groesbeek" <rgroesb AT triple-it DOT nl>
To: "Corinna Vinschen" <cygwin AT cygwin DOT com>
Subject: Cygwin && TCP && O_NONBLOCK
Date: Fri, 14 Jun 2002 04:08:58 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=3.5, required 5,
	UNSUB_PAGE)
Note-from-DJ: This may be spam

                                    Hi All,

(The Cygwin && UDP && O_NONBLOCK bug has been solved. See Appendix)

New problem, well more kind of behaviour question, but in this case for
TCP && O_NONBLOCK sockets.

Situation:
=======
- 1 NON_BLOCKING tcp socket
- First connect() gives EINPROGRESS
- Second connect() gives:
  * On Linux: nResult == 0
  * On Cygwin: nResult == -1 && errno == EISCONN


Question:
=======
Which behaviour is right?
Where could I check the specifications for the implementations?


Piece of code:
===========

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int
CTcpSock::Reconnect()
{
  _deb_("ReConnecting\n");
  int nResult =
    ::connect(m_nFd, (struct sockaddr *) &m_strName, sizeof(m_strName));
  if (nResult < 0 && errno == EINPROGRESS)
  {
    _deb_("connect() in Progress: %s\n", ::strerror(errno));
    m_cState= S_CONNECTING;
    return 1;
  }
  if (nResult == 0)
  {
    _deb_("connect() Succeeded\n");
    m_cState = S_CONNECTED;
    return 1;
  }
//#ifdef CYGWIN
  if (nResult == -1 && errno == EISCONN) {
    _deb_("connect() Succeeded\n");
    m_cState = S_CONNECTED;
    return 1;
  }
//#endif
  _warn_("Reconnect() Failed!: %s|%d|nResult=%d\n", ::strerror(errno),
errno, nR
esult);
  CheckWriteable(FALSE);
  m_cState = S_ERROR;
  return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Thnx for your time.

Vriendelijke Groet,

Roderick
--
Pettemerstraat 12A                                  T r I p l e
1823 CW Alkmaar                                         T
Tel. +31 (0)72-5129516
fax. +31 (0)72-5129520                              Automatisering
www.triple-it.nl                                 "Laat uw Net Werken!"

Appendix A:
=========
----- Original Message -----
From: Corinna Vinschen
To: cygwin AT cygwin DOT com
Sent: Wednesday, August 15, 2001 9:50 AM
Subject: Re: 1.3.2: Cygwin && UDP && O_NONBLOCK


On Tue, Aug 14, 2001 at 01:54:27PM -0600, Troy Noble wrote:
> Roderick,
>
> Unless I misunderstood entirely, I think you've found a bug.
>
> I got the same blocking behavior you described when testing
> (after fixing many of the same things that Keith
> described in his mail).  And it does appear to be inconsistent
> with behavior on Linux for the same program as you noted.
>
> Looks like there was a fix for some code related to setting up the
> non-blocking behavior in fhandler_socket.cc:fctl on Aug 13, 2001
> so the flags are set properly now, but the recvfrom appears not
> to be checking for the non-blocking flag.  I updated my src tree
> from CVS today and tested, and it still exhibits the blocking
> behavior you describe.
>
> The problem appears to be the wait for an event at net.cc:93
> which looks like:
>
>   switch (WSAWaitForMultipleEvents(2, ev, FALSE, WSA_INFINITE, FALSE))
>
> There seem to be at least two ways to fix it, otherwise I'd just
> submit a patch.  But I don't know that I understand the philosopy
> entirely, so it'd be best to defer to Corinna's better judgement.
>
> It seems to me in net.cc:recvfrom one of the following
> needs to happen:
>
> 1. if ((h->get_flags() & O_NONBLOCK_MASK)
>        || !(ovr = wsock_evt.prepare ()))
>     {
>        ...
>
>    which would cause behavior to revert to Winsock 1.1's
>    recvfrom which appears to do the right thing, at least in
>    my minimal testing.

Thanks for tracking that down. I changed the code to use your
version 1 (fallback to winsock1) in case of nonblocking sockets.

Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/