[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!