X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 14 Dec 2007 14:41:47 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: VM and non-blocking writes
Message-ID: <20071214134147.GG25863@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <47616D31 DOT 7090002 AT 4raccoons DOT com> <20071213175934 DOT GB25863 AT calimero DOT vinschen DOT de> <476185AF DOT 5000906 AT 4raccoons DOT com> <20071214111508 DOT GD25863 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20071214111508.GD25863@calimero.vinschen.de>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Dec 14 12:15, Corinna Vinschen wrote:
> On Dec 13 11:19, Wayne Christopher wrote:
> > Okay, here's my test program. 
> > [...]
> I can reproduce this behaviour.  Stepping through the code shows that
> the socket has been successfully switched to non-blocking (the WinSock
> ioctlsocket function returns with success).  But the WinSock function
> WSASendTo hangs for a while and returns with SOCKET_SUCCESS and the
> number of bytes written is 100000000. 
> 
> Since the peer doesn't read these bytes, it appears that WSASendTo
> creates a temporary buffer in kernel space and copies the full user
> buffer into this temporary buffer.  When I raised the memory buffer to
> 512K, the WSASendTo function failed with WSAENOBUFS, "No buffer space
> available."
> 
> This is really surprising.  The socket write buffer size on Windows is
> usually 8K, afaik, if you don't change it with setsockopt(SO_SNDBUF).
> Why it tries to buffer more than this 8K beats me.  I searched the net
> for this problem but I didn't find any other report which would describe
> such a weird behaviour.
> 
> However, I have to make some more tests, especially in a pure Win32
> application to be sure that it's not a Cygwin problem only.

I can reproduce this behaviour with a native Windows application.  It
does not depend on using WSASendTo vs. using send, and in case of
using WSASendTo it happens independently of using one big WSABUF
element or multiple smaller elements.  I can reproduce the behaviour
on Windows 2000 SP4, XP SP2 and Vista SP1 RC1, so it's not even OS
dependent.

On the other hand, as soon as I call send (or WSASendTo) multiple
times with smaller sizes (I tried with 10k), select starts to
block at one point.  But even then strange things happen.  After
some time (after 5 seconds, then after 14 seconds, then about every
60 seconds) select() just signals the socket ready for write and
the next send adds another 10K to the internal buffer.  A tcpdump
on the interface shows that no package goes over the line... which
would be a surprise anyway, given that the peer does not even once
call read().

Given that, I don't see what we can do about this misbehaviour.
I guess I'll report this as a bug and see what the reaction will
be.  Especially if there's a useful workaround.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/