delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2002/07/04/08:28:36

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: Thu, 4 Jul 2002 14:28:29 +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: Interruptable connect
In-Reply-To: <20020704141359.S21857@cygbert.vinschen.de>
Message-ID: <Pine.WNT.4.44.0207041420180.250-100000@algeria.intern.net>
X-X-Sender: pfaff AT antarctica DOT intern DOT net
MIME-Version: 1.0


On Thu, 4 Jul 2002, Corinna Vinschen wrote:

> On Thu, Jul 04, 2002 at 01:54:33PM +0200, Thomas Pfaff wrote:
> >
> > I am trying to get an interruptable connect and i have some difficulties.
> >
> > The main problem is that it seems to be impossible to cancel a nonblocking
> > connect other than closing the socket. I already thought about closing the
> > socket and replacing it with a new one, but this requires that all
> > sockoptions and states have to be restored for the new one execpt the
> > pending connect.
> >
> > Another possibility is to set errno to EINTR, return and let the
> > connect keep going.
> > The app can now react in different ways :
> >
> > The signal handler terminates the program.
> > Perfect.
> >
> > The program checks for the error and close the socket.
> > Good.
> >
> > connect is called in a loop like
> > do {
> >   res = connect(...);
> >   if (!res)
> >     break;
> > } while(errno==EINTR);
> > Now the program returns to the connect function, the real connect returns
> > WSAEALREADY or WSAEISCONN, it can be checked that the connect was
> > interrupted and it can be continued.
> > No big deal.
> >
> > The error is ignored and the socket is not closed:
> > Now there are 2 possibilies.
> >
> > a. The connect fails.
> > No problem.
> >
> > b. The connect succeds. Now exists an orphaned connection that can block
> > the partner.
> > Sigh.
> >
> > Any suggestions ?
>
> Could you start a thread waiting for the result of the connect
> and close it if it isn't already closed?
>

Sure, but how will this help ? You can not look ahead if the connect will
be reentered or not. If the program is well written it will or close the
socket afterwards, but should i rely on this ?

Thomas

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019