Mail Archives: cygwin-developers/2001/10/30/06:50:03

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <>
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 <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Spurious EWOULDBLOCKs on NT4.0
Message-ID: <>
Reply-To: cygdev <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20011030003901 DOT A8989 AT redhat DOT com>
Mime-Version: 1.0
User-Agent: Mutt/1.2.5i
In-Reply-To: <>; from 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.


> cgf
> Index:
> ===================================================================
> RCS file: /cvs/uberbaum/winsup/cygwin/,v
> retrieving revision 1.32
> diff -u -p -r1.32
> ---	2001/10/29 05:28:24	1.32
> +++	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.

- Raw text -

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