delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/03/30/04:03:29

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <20040330090300.81137.qmail@web60310.mail.yahoo.com>
Date: Tue, 30 Mar 2004 01:03:00 -0800 (PST)
From: Patrick Samson <p_samson AT yahoo DOT com>
Subject: Re: Postgres Backend doesn't catch the next command, after SIGUSR2
To: cygwin AT cygwin DOT com
In-Reply-To: <20040329141651.GZ17229@cygbert.vinschen.de>
MIME-Version: 1.0
X-IsSubscribed: yes

--- Corinna Vinschen wrote:
> When WSAWaitForMultipleEvents returns
> WSA_WAIT_EVENT_0 + 1, you can be
> sure that the event hasn't happen at this point. 
> Otherwise it would
> have returned WSA_WAIT_EVENT_0.  Unfortunately this
> doesn't mean that
> the event couldn't happen a nanosecond later.
> 
> If the signal has arrived and the WSARecvFrom call
> should be interrupted,
> you can't just go ahead, since the call to
> WSARecvFrom got a pointer
> to application allocated memory.  You can't rely on
> the fact that the
> application will keep this memory intact after
> recvfrom returned with
> EINTR.  If you do, Windows might scramble
> application memory.  To avoid
> that, the CancelIo cancels the active call.
> 
> Having said that, does the below change at least
> alleviates the problem?
> 
> The implementation would have to be changed a bit
> more to get this
> entirely non-racy, though.
> 
> Corinna
> 
> Index: net.cc
>
===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/net.cc,v
> retrieving revision 1.162
> diff -u -p -r1.162 net.cc
> --- net.cc	29 Mar 2004 14:08:44 -0000	1.162
> +++ net.cc	29 Mar 2004 14:09:17 -0000
> @@ -83,7 +83,9 @@ wsock_event::wait (int socket,
> LPDWORD f
>  	  ret = (int) len;
>  	break;
>        case WSA_WAIT_EVENT_0 + 1:
> -	if (!CancelIo ((HANDLE) socket))
> +	if (WSAGetOverlappedResult (socket, &ovr, &len,
> FALSE, flags))
> +	  ret = (int) len;
> +	else if (!CancelIo ((HANDLE) socket))
>  	  {
>  	    debug_printf ("CancelIo() %E, fallback to
> blocking io");
>  	    WSAGetOverlappedResult (socket, &ovr, &len,
> TRUE, flags);
> 

Probably Yes, but even reduced, there is still room
between WSAGetOverlappedResult and CancelIo to loose
data.

What about first cancel the I/O op and then look
for possible data?
From msdn:
"All I/O operations that are canceled will complete
with the error ERROR_OPERATION_ABORTED. All completion
notifications for the I/O operations will occur
normally."
What's your feeling about:
if (!CancelIo ((HANDLE) socket))
  {...}
else
  {
   if (WSAGetOverlappedResult (socket, &ovr, &len,
 FALSE, flags) && len != 0)
    ret = (int) len;
   else WSASetLastError (WSAEINTR);


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


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