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 Message-ID: <011b01c23748$9396c5e0$6132bc3e@BABEL> From: "Conrad Scott" To: References: <010901c23724$96e5d430$6132bc3e AT BABEL> <3D4581E4 DOT BB580995 AT ieee DOT org> <005801c23730$02304170$6132bc3e AT BABEL> <20020729192037 DOT GA19335 AT redhat DOT com> Subject: Re: TCP problems Date: Mon, 29 Jul 2002 22:40:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 "Christopher Faylor" wrote: > If you're just talking about system-wide closes then you could use > the technique currently employed in pipe.cc where events are used > as flags indicating when the "other side" of a pipe is closed. That's a nice trick: each time the write-end of the pipe is duplicated so is the handle to a named event created when the pipe was created; so, if you try and fail to open the event, all instances of the write-end have been closed. Very simple and it survives applications being killed via the task manager too. I'll see if I can use that trick to simplify the UNIX domain socket patch I submitted. I can't immediately see how, since I want the code to block until something in particular happens, but it would simplify the detection of the last close. Thanks, // Conrad p.s. I like the name of the event too: "stupid_pipe" ;-)