On Dec 17 19:24, Corinna Vinschen wrote:
> On Dec 17 12:28, Lev Bishop wrote:
> > 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 sur
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
> > > t
On Dec 16, 2007 9:07 AM, Corinna Vinschen wrote:
> On Dec 16 14:42, Corinna Vinschen wrote:
> > I'm contemplating the idea to workaround this problem in Cygwin (not
> > for 1.5.25, but in the main trunk) by caping the number of bytes in a
> > single send call, according to the patch Lev sent
On Dec 16 14:42, Corinna Vinschen wrote:
> I'm contemplating the idea to workaround this problem in Cygwin (not
> for 1.5.25, but in the main trunk) by caping the number of bytes in a
> single send call, according to the patch Lev sent in
> http://www.cygwin.com/ml/cygwin-patches/2006-q2/ms
On Dec 15 12:29, Robert Pendell wrote:
> Corinna Vinschen wrote:
> > Obviously I searched wrong. There a reports about this behaviour
> > since at least 1998 and it has never been fixed. These two links
> > might be interesting:
> >
> > http://support.microsoft.com/kb/q201213/
> > http://tin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Corinna Vinschen wrote:
> On Dec 14 12:15, Corinna Vinschen wrote:
>> I searched the net
>> for this problem but I didn't find any other report which would describe
>> such a weird behaviour.
>
> Obviously I searched wrong. There a reports about th
On Dec 14 09:34, Lev Bishop wrote:
> http://www.cygwin.com/ml/cygwin-patches/2006-q2/msg00031.html
Gosh, I didn't even remember this discussion anymore, sorry.
> There's a whole bunch of tuning parameters that deal with when afd
> should make a copy of an application-supplied buffer [...]
> You c
On Dec 14, 2007 8:52 AM, Corinna Vinschen wrote:
> On Dec 14 14:41, Corinna Vinschen wrote:
> > 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
>
On Dec 14 12:15, Corinna Vinschen wrote:
> I searched the net
> for this problem but I didn't find any other report which would describe
> such a weird behaviour.
Obviously I searched wrong. There a reports about this behaviour
since at least 1998 and it has never been fixed. These two links
m
On Dec 14 14:41, Corinna Vinschen wrote:
> 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 a
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 r
On Dec 13 11:19, Wayne Christopher wrote:
> Okay, here's my test program. Compile and run with no arguments, then
> connect to it from another machine - on a linux box I just did:
>
> python
> import socket
> s = socket.socket()
> s.connect(("name-of-windows-box", 12345))
>
> At this point, nbchec
Okay, here's my test program. Compile and run with no arguments, then
connect to it from another machine - on a linux box I just did:
python
import socket
s = socket.socket()
s.connect(("name-of-windows-box", 12345))
At this point, nbcheck printed:
listening to port 12345 on host xp1 (10.1.2.4
On Dec 13 09:34, Wayne Christopher wrote:
> I have a server application that runs on XP under the latest cygwin, that
> opens up a socket connection to a client on another system, makes that
> socket non-blocking using fcntl( O_NDELAY), and then feeds the client a
> large file (100's of MBs)
On 13 December 2007 17:35, Wayne Christopher wrote:
> What I see is that no matter how large the size is that I give to
> write(), the return value is always the full size. Also, I see the
> virtual memory used by my process go way up - in fact it goes up by much
> more than the amount of data I'
I have a server application that runs on XP under the latest cygwin,
that opens up a socket connection to a client on another system, makes
that socket non-blocking using fcntl( O_NDELAY), and then feeds the
client a large file (100's of MBs) by doing the following:
1. call write() with th
16 matches
Mail list logo
