Mail Archives: cygwin/2002/06/13/22:09:34
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/
- Raw text -