Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Thu, 4 Jul 2002 16:11:16 +0200 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: Interruptable connect Message-ID: <20020704161116.U21857@cygbert.vinschen.de> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i On Thu, Jul 04, 2002 at 02:54:44PM +0200, Thomas Pfaff wrote: > > 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. I see. The question is if we're able to get around that Winsock'ism. Perhaps Winsock2 helps a bit. This is just brainstorming, I have no idea if that works: When connect is called, create a duplicate of the socket first, before actually connecting, using the WSADuplicateSocket call. This should give you a structure describing the socket in exactly the state before the ::connect call. Now for the cases: - Normal connect, success, erase the duplicate. - Normal connect, failure, ditto. - Interrupt, close original socket and recreate it from the duplicate using WSASocket. Would that work??? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.