Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Tue, 30 Oct 2001 12:49:51 +0100 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: Spurious EWOULDBLOCKs on NT4.0 Message-ID: <20011030124951.A891@cygbert.vinschen.de> Reply-To: cygdev Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20011030003901 DOT A8989 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011030003901.A8989@redhat.com>; from cgf@redhat.com on Tue, Oct 30, 2001 at 12:39:01AM -0500 On Tue, Oct 30, 2001 at 12:39:01AM -0500, Christopher Faylor wrote: > I thought that I would try to duplicate the ftpd/rsync problems on > my laptop under NT4.0. However, I'm now noticing that I'm getting > occasional EWOULDBLOCK/EAGAIN errors from ssh. I repeatedly get > them when copying a 1K+ file, on close. Not every time, though. > > The actual winsock error is WSAEWOULDBLOCK. > > I think that this is due to the relatively "recent" addition of the > setsockopt(...LINGER...) in fhandler_socket::close. This is borne out > by the fact that I can't duplicate the problem in 1.3.2. > > The code below seems to "fix" this problem but I'm not sure it is > correct. According to SUSv2, close is supposed to be a quick operation > unless SO_LINGER is used... > > Hmm. In fact, it must be wrong since this could make close block > indefinitely. > > Another way of doing this is to ignore WSAEWOULDBLOCK errors in > fhandler_socket::close. Maybe that's more correct. > > Anyone know what's happening here? Corinna? I think, yes. WSAEWOULDBLOCK is raised by closesocket if the socket is nonblocking and SO_LINGER is set to a non-zero value. The below code is probably more correct than the previous one. Our problem is the combination of closesocket/exit which, when too fast, results in data loss on not already finished connections on process exit. This sappy behaviour is what we have to avoid, therefore it's correct to wait unless close has _really_ finished it's job even on nonblocking sockets and even if that's "not recommended" by MSDN. AFAIK, the below code can't loop forever since closesocket() will return either 0 or another error code at one point. What I'm just missing now is the error handling after finishing the closesocket() loop. I added that to the repository. Corinna > cgf > > Index: fhandler_socket.cc > =================================================================== > RCS file: /cvs/uberbaum/winsup/cygwin/fhandler_socket.cc,v > retrieving revision 1.32 > diff -u -p -r1.32 fhandler_socket.cc > --- fhandler_socket.cc 2001/10/29 05:28:24 1.32 > +++ fhandler_socket.cc 2001/10/30 05:30:36 > @@ -287,11 +287,9 @@ fhandler_socket::close () > setsockopt (get_socket (), SOL_SOCKET, SO_LINGER, > (const char *)&linger, sizeof linger); > > - if (closesocket (get_socket ())) > - { > - set_winsock_errno (); > - res = -1; > - } > + while (closesocket (get_socket ()) > + && WSAGetLastError () == WSAEWOULDBLOCK) > + continue; > > close_secret_event (); > -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.