Jason Tackaberry wrote: > On Mon, 2005-10-31 at 18:14 +0100, Dirk Meyer wrote: >> Won't work. In my case I want to send 200k data. This would block, so >> we can an exception. But we can send, so we enter this function again, >> but not 200k, so we leave again. You need to send in 4k pieces to be sure. > > I was under the impression send() will send as much as it can. The docs > for send() says: > > Applications are responsible for checking that all data has been > sent; if only some of the data was transmitted, the application > needs to attempt delivery of the remaining data.
OK, looks like you are right and it was caused by the fact that you
wanted to send on a full queue. It is a problem when you do the stuff
in C. I guess Python is doing the 4k stuff internaly. If you read "man
2 socket":
If the message is too long to pass atomically through the underly-
ing protocol, the error EMSGSIZE is returned, and the message is
not transmitted.
So it is a problem in C.
> Why is the problem solved with 4k chunks? What if the socket is
> connected over a slow modem? Sending 4k could block too.
No, the OS will buffer it.
> If it works as you've described, the problem is not fundamentally
> fixed. Just hidden because our wire is fast.
No, you can only be sure to send one block (4k) in C. So Python has to
split the data into pieces. Believe me, I tried. :(
> Instead, if send() will send as much as it can without blocking
> (which I assume just means moving some chunk of data to the kernel's
> network buffers) and returns the number of bytes it was able to
> dispose, it should work properly as it's coded now.
It does. I had a problem and switched to my C code. And there you have
the 4k problem.
Dischi
--
"Software is like sex: it's better when it's free.", Linus Torvalds
pgp10Yjmv4MEh.pgp
Description: PGP signature
