VM and non-blocking writes

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Dec 17 20:22:00 GMT 2007

On Dec 17 12:28, Lev Bishop wrote:
> On Dec 16, 2007 9:07 AM, Corinna Vinschen wrote:
> > On Dec 16 14:42, Corinna Vinschen wrote:
> > >   Lev, are you interested in reworking your patch (minus the pipe stuff)
> > >   to match current CVS?  Is there any gain in raising SO_SNDBUF/SO_RCVBUF
> > >   to a value > 8K, especially in the light of my experiences commented
> > >   on in net.cc, function fdsock()?
> >
> > Lev, do you have a copyright assignment in place?  I don't find you on
> > my list of signers.
> No I don't have a copyright assignment in place yet. I will see what I
> can do about that -- don't think it will be a problem. I'd be
> interested in reworking the patch against current CVS (though I
> haven't looked to see how far current CVS has moved so I don't know
> how much that will involve). But I have to warn you in advance that I
> haven't had much time to work on this stuff, and I don't see that
> situation changing any time soon, so it may take multiple weeks before
> I get a chance [...]

It's not time critical.  The next major release will take some more
time anyway.  If you just could send the copyright assignment, it wou;d
be a good start.

> Having said all that, the winsock default 8kb really is far too small
> for many situations. I find that in my tests (this may be network
> hardware/driver dependent) I need 32kb for the stack to start
> coalescing packets reliably. Based on this, and on the problems
> described in your comments of net.cc fdsock() where the issue was with
> 64kb buffer size, it seems that 32kb would be a good size to use
> (again, it's possibly better to recommend the user to alter his
> registry setting to 32kb, rather than have cygwin force it through
> setsockopt()).

We could just check if the parameter is still set to 8K and only change
it to 32K if so.  Since that already happens at socket creation time,
it doesn't affect later settings in the application anyway, isn't it?

> Before getting too set on the plan of having cygwin break
> applications' send()s into chunks, maybe it's worth reconsidering the
> overall strategy. We're basically at this point implementing our best
> attempt at BSD semantics on top of microsoft's half-assed attempt at
> BSD semantics on top of the native not-BSD-like-at-all but powerful
> and quite self-consistent NT semantics. If we keep having to work
> around more issues like this, perhaps we'd be better off bypassing the
> afd layer entirely, by setting SO_SNDBUF to 0, using overlapped IO,
> and managing buffers ourselves. I'm sure this would bring it's own set
> of complications, but at least we'd be in a better position to deal
> with them, not having to go through the afd layer. What do you think?

Sorry, I'm unfamiliar with the native NT socket interface :} Is there
somewhere a (good) tutorial for the native NT socket stuff?  Even
without using the native API, we could also just set the Winsock
SO_RCVBUF/SO_SNDBUF settings to 0 and intercept the setsockopt/getsockopt
calls to maintain our own buffers, right?

Having said that, for a start I would prefer a simple "upgrade" along
the lines of your previous patch.


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/

More information about the Cygwin mailing list