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

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:54:44 +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: <Pine.WNT.4.44.0207041420180.250-100000@algeria.intern.net>
Message-ID: <Pine.WNT.4.44.0207041449070.141-100000@algeria.intern.net>
X-X-Sender: pfaff AT antarctica DOT intern DOT net
MIME-Version: 1.0


On Thu, 4 Jul 2002, Thomas Pfaff wrote:

>
>
> 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 ?
>

To be more precise:
I have no problems with unclosed sockets but with a connected socket
that shouldn't be connected.

Thomas


- Raw text -


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