Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: Thu, 10 May 2001 14:07:21 -0400 From: Christopher Faylor To: cygwin@cygwin.com Cc: fred@ontosys.com Subject: Re: SIGTERM does not stop backend postgres processes immediately Message-ID: <20010510140721.F12136@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com, fred@ontosys.com References: <20010510112639.A26981@enteract.com> <20010510123102.B15024@redhat.com> <20010510123628.A48047@enteract.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <20010510123628.A48047@enteract.com>; from fred@ontosys.com on Thu, May 10, 2001 at 12:36:28PM -0500 On Thu, May 10, 2001 at 12:36:28PM -0500, Fred Yankowski wrote: >On Thu, May 10, 2001 at 12:31:02PM -0400, Christopher Faylor wrote: >> Remember this? >> >Unfortunately, blocking recv() calls are not interruptible on Windows. >> >I'm not aware of any mechanism for allowing this. > >Some research led me to believe that closesocket() could unblock a >Win32 recv() call. > >> What do you think a signal handler does? It would need to interrupt >> a blocking recv() to work, wouldn't it? > >Are you saying that a blocking recv() _must_ never be interrupted, I didn't say "must". I said "can't". >even if a mechanism exists that would make that possible? What mechanism is this? You have already demonstrated that you can't use Cygwin signals to interrupt a recv. You seem to be using circular reasoning: "Hmm. I'm having problems with getting signals to interrupt a recv() call. Chris says that recv calls can't be interrupted but someone else says that closesocket works. So, I know! I'll use a *signal* to interrupt the recv call and close the socket!" Perhaps this would work if you used another thread but there is no mechanism in cygwin for doing this currently and I really doubt that closing a socket is the right solution for dealing with this problem. >If so, what is the basis for that decision? The recv() specified by >the Open Group [1] seems to allow for an EINTR error case. I'll bet the the Open Group would imply that a signal does not close a socket if you are blocked in a recv() call, too. I don't know why you are getting the impression that I'm passing down an edict. I'm always open to methods for getting Cygwin to work more like UNIX. I don't see how closing the socket can achieve this goal, even if you could make it work. cgf -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple