Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From: "Dave Korn" <dk AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: 1.5.12: non-blocking connect fails: deprecated method
Date: Fri, 19 Nov 2004 14:56:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <419DFE72.3080405@palli.nl>
Message-ID: <NUTMEGts601otddfbTF000000dd@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 19 Nov 2004 14:56:34.0343 (UTC) FILETIME=[F64C9370:01C4CE47]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Ivo Palli
> Sent: 19 November 2004 14:09

> Hi,
> 
> I ran into a backward compatibility issue with Cygwin.

  Actually, the correct term for these sorts of issues is
"bugwardly-compatible".  Read on:

> When doing a non-blocking connect, you do a connect with a non-blocking 
> fd, wait for the select() to report it back as writable, and then 
> perform a getsockopt() to check the status of the fd.

  Yep.

> However in older code (including mine, I upgraded it now however) you 
> will find that instead of calling getsockopt(), they will 
> call connect again (exactly as the initial call).

  That's utterly incorrect code then.  The term is not "upgraded": it is
"fixed".  Or "corrected".  Or "debugged".

> Connect in cygwin gives: Transport endpoint is already connected
> 
> But Linux 2.4.22 will return 0 and accept the socket as 
> connected. 

  Then Linux 2.4.22 is buggy.  There are *no* circumstances under which
connect should return zero when you repeat the call.

http://www.opengroup.org/onlinepubs/009695399/functions/connect.html

If the connection cannot be established immediately and O_NONBLOCK is set
for the file descriptor for the socket, connect() shall fail and set errno
to [EINPROGRESS], but the connection request shall not be aborted, and the
connection shall be established asynchronously. Subsequent calls to
connect() for the same socket, before the connection is established, shall
fail and set errno to [EALREADY].

[ snip ]

ERRORS
The connect() function shall fail if:

[ snip ]

[EALREADY] 
A connection request is already in progress for the specified socket. 

[ snip ]

[EISCONN] 
The specified socket is connection-mode and is already connected. 

> You might want to support the older behaviour also.

  I don't think it's a good idea to *introduce* a bug into cygwin just
because Linux *used* to have such a bug.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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