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

[Guido van Rossum]

> On Fri, Aug 11, 2000 at 03:55:01PM +0200, Fredrik Lundh wrote:
> > guido wrote:
> > > I just read the man page for send() (Red Hat linux 6.1) and it doesn't
> > > mention sending fewer than all bytes at all.  In fact, while it says
> > > that the return value is the number of bytes sent, it at least
> > > *suggests* that it will return an error whenever not everything can be
> > > sent -- even in non-blocking mode.
> 
> > > Under what circumstances can send() return a smaller number?
> 
> > never, it seems:
> 
> [snip manpage]
> 
> 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 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???)

> Someone set the patch to 'rejected' and tell the submittor that 'send'
> doesn't return the number of bytes written ;-P

Done.

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

Could there be a signal interrupt issue here too?  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
(2) continue
(3) return the number of bytes already written

???

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)