[Python-Dev] noreply@sourceforge.net: [Python-bugs-list] [Bug #111620] lots of use of send() without verifyi ng amount of data sent. (original) (raw)

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!