Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
X-Authentication-Warning: atacama.four-d.de: mail set sender to <tpfaff AT gmx DOT net> using -f
Date: Mon, 8 Jul 2002 09:26:24 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=)
From: Thomas Pfaff <tpfaff AT gmx DOT net>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Select with nonblocking connects
In-Reply-To: <20020705155221.P21857@cygbert.vinschen.de>
Message-ID: <Pine.WNT.4.44.0207080919460.118-100000@algeria.intern.net>
X-X-Sender: pfaff AT antarctica DOT intern DOT net
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Fri, 5 Jul 2002, Corinna Vinschen wrote:

> On Fri, Jul 05, 2002 at 03:20:19PM +0200, Thomas Pfaff wrote:
> >
> > I guess the easiest way is to add a flag in fhandler_socket that is set
> > when a connect is in progress. If it is set then add the sock handle to
> > exceptfds as well. After select returns check the exceptfds, if the socket
> > is signaled set it in writefds too. In UNIX you have to check the SO_ERROR
> > sockopt to know if the connect has succeded or failed, but winsock sets is as
> > well. Now clear the in_progress flag.
> >
> > For listening sockets i see no difference.
>
> Huh?  The problem is the same as long as neither connect() nor listen()
> have been called, nor a non-blocking connect() has succeeded.  In either
> case, the WinSock select() blocks if the SOCKET is given in write_fd,
> while the Linux select() returns with the fd set in write_fd.
> The difference is just the SO_ERROR value which is 0 as long as neither
> connect() nor listen() have been called, resp EINPROGRESS in case of a
> not finshed connect().
>
> I'm not talking about a listening socket.  I'm talking about a socket in
> neither listening nor connected state.

Sorry for the mistake. I could not imagine that someone call select with a
socket that is neither connected nor listening nor pending.
What is he expecting to get ?

Thomas