This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VM and non-blocking writes

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

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]