[Python-Dev] noreply@sourceforge.net: [Python-bugs-list] [Bug #111620] lots of use of send() without verifyi ng amount of data sent.
Thomas Wouters
thomas@xs4all.net
Fri, 11 Aug 2000 18:44:07 +0200
On Fri, Aug 11, 2000 at 10:56:06AM -0500, Guido van Rossum wrote:
> > Indeed. I didn't actually check the story, since Guido was apparently
> > convinced by its validity.
> I wasn't convinced! I wrote "is this true?" in my message!!!
I appologize... It's been a busy day for me, I guess I wasn't paying enough
attention. I'll try to keep quiet when that happens, next time :P
> > I was just operating under the assumption that
> > send() did behave like write(). I won't blindly believe Guido anymore ! :)
> I bgelieve they do behave the same: in my mind, write() doesn't write
> fewer bytes than you tell it either! (Except maybe to a tty device
> when interrupted by a signal???)
Hm, I seem to recall write() could return after less than a full write, but
I might be mistaken. I thought I was confusing send with write, but maybe
I'm confusing both with some other function :-) I'm *sure* there is a
function that behaves that way :P
> Note that send() *does* return the number of bytes written. It's just
> always (supposed to be) the same as the length of the argument string.
> Since this is now established, should we change the send() method to
> raise an exception when it returns a smaller number? (The exception
> probably should be a subclass of socket.error and should carry the
> number of bytes written
Ahh, now it's starting to get clear to me. I'm not sure if it's worth it...
It would require a different (non-POSIX) socket layer to return on
'incomplete' writes, and that is likely to break a number of other things,
too. (Lets hope it does... a socket layer which has the same API but a
different meaning would be very confusing !)
> Could there be a signal interrupt issue here too?
No, I don't think so.
> E.g. I send() a megabyte, which takes a while due to TCP buffer limits;
> before I'm done a signal handler interrupts the system call. Will send()
> now:
> (1) return a EINTR error
Yes. From the manpage:
If the message is too long to pass atomically
through the underlying protocol, the error EMSGSIZE is
returned, and the message is not transmitted.
[..]
ERRORS
EINTR A signal occurred.
[..]
Because send() either completely succeeds or completely fails, I didn't see
why you wanted an exception generated :)
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!