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, 25 Jul 2002 16:54:02 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: Signals and the such-like Message-ID: <20020725205402.GC6611@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <00af01c2341b$b6138890$6132bc3e AT BABEL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00af01c2341b$b6138890$6132bc3e@BABEL> User-Agent: Mutt/1.3.23.1i On Thu, Jul 25, 2002 at 09:41:53PM +0100, Conrad Scott wrote: >[Sorry: Long email] > >About a week ago I discovered a race condition in the UNIX domain >socket emulation in cygwin. I've got a patch for this that works >(and fixes several other small problems) bar one *minor* issue and >since I'm out of ideas, I hope someone else out there has got some >advice for me (even if it's only "don't do that!"). > >Here goes. I've put together a new UNIX domain handshake >protocol, but somewhere it's got to pause long enough for the >server to pick up the client's half of the protocol, since with a >socket a client can get connection, write some data and close the >socket before the server has accepted the connection (the >connection's just sitting on the pending queue). > >So, I've got a piece of code in the fhandler_socket::close method >that only closes the client's secret event once the client has >received the server's okay signal *or* a (Unix) signal arrives >*or* the server closes its end of the connection (i.e. the server >exits w/o ever accepting the connection). What is an "ok" signal in this context? Are you introducing handshaking between two processes that wasn't there originally? That sounds dangerous. It sounds like you will have permission problems to worry about. >This is all fine and dandy except for two situations: if the >client receives an unhandled signal that should cause it to die >*or* if the client exits w/o closing the socket. At this point, >if the server is blocked itself and not accepting the connection, >the client will not exit and can't be ctrl-c'd either. The >problems in the two situations are caused by the same issue: > >*) If the client receives an unhandled signal, e.g. SIGINT, the >do_exit function is called, which then calls close_all_files. But >it does this w/o setting the 'signal_arrived' event, so none of >the events are set that the fhandler_socket::close method is >waiting on (at least, not in the particular circumstances >mentioned here). Actually, this is by design. The process is exiting. It's trying to exit quickly and not wake up any sleeping threads. This reduces, but does not eliminate, potential races or deadlocks. If you set signal_arrived, you're going to have two threads operating at the same time with unpredictable results. We try hard to avoid situations where we rely on cygwin processes behaving predictably on exit. In your scenario, it sounds like you would have a hang situation if a process is terminated from the task manager. cgf