Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Corinna Vinschen <cygwin AT cygwin DOT com>
Date: Mon, 11 Dec 2000 20:15:20 +0100
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="us-ascii"
To: cygwin AT cygwin DOT com
References: <1529f1887b DOT 1887b1529f AT uth DOT tmc DOT edu> <00120813285702 DOT 12851 AT cygbert> <14900 DOT 63927 DOT 152000 DOT 146634 AT gargle DOT gargle DOT HOWL>
In-Reply-To: <14900.63927.152000.146634@gargle.gargle.HOWL>
Subject: Re: socket read()/write() problem in 1.1.6 [solved]
MIME-Version: 1.0
Message-Id: <00121120152002.00475@cygbert>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id OAA26528

On Monday 11 December 2000 16:58, Markus Hoenicka wrote:
> Finally it turns out that my problem was indeed a timing problem -
> not the read()/write() timing problem that Corinna suspected but a
> timing problem when closing the socket from the server side. I was
> not aware that my server relied on a certain time passing between the
> last write() on the server side and the closing of the socket as it
> was obscured by lots of cleanup code in my original program. This got
> clearer and clearer the simpler my testcases got. The newer Cygwin
> versions apparently speed up this cleanup or the closing of the
> socket and thus expose the flawed design of my server. Of course it
> is easy to work around this once you know.
>
> I'm sorry for the noise that I created, but putting together the
> testcases and Corinna's input finally helped me to see the problem.

This is a lucky conincidence. I had just tracked down the problem to
a point where I finally saw that no graceful shutdown is made.

However, it's not only a problem of your code alone. I read the
description of closesocket(), shutdown() etc. etc. in MSDN to find
out the following.

closesocket() behaves different dependent on the SO_LINGER option
set. The default behaviour of SO_DONTLINGER which results in a
immediate return while the connection is gracefully shutdown
in the background.

The new Cygwin socket code doesn't use standard handle duplication
on socket inheritance between processes but the special Winsock2
functions WSADuplicateSocket() and WSASocket().

When calling closesocket() on duplicated sockets using the above
Winsock2 method, closesocket() seems to act as if SO_LINGER with
zero time-out is enabled which results in closesocket() returning
immediately while forcing an immediate termination of the
connection.

That behaviour is not documented in the MSDN, AFAICS.

I tried various workarounds but the only reliable way seems to
be to perform a graceful shutdown in the application.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com