Author vstinner
Recipients vstinner
Date 2016-02-05.08:51:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
"(it's probably broken with non-blocking streams too, for the same

Yes it is :-)

We hitted this issue on eventlet when I changed the socket.send() method in eventlet 0.18 to stop sending data on partial write, whereas eventlet < 0.18 used a loop to ensure that all bytes are written.

The side effect of my change is that (indirectly) socket.makefile().writelines() may also use partial write if the underlying send() only writes partially data.

The problem is that writelines() has *no* result, so the caller cannot be aware of the partial write and data is lost...


* send() change:
* writelines() bug:

"In the spirit of RawIO.write(), I think RawIO.writelines() could return
the number of bytes written (allowing for partial writes)."

I don't know yet what is the best option for eventlet, but we should probaly enhance the Python stdlib io module to return something on writelines() and *document* the behaviour on partial write.

The problem writelines() API is that writelines() not only takes a single text/bytes string, but a *list* of text/bytes strings.

Another option is to modify to retry on partial write to ensure that all data is written. If the underlying write() method returns None (blocking I/O error), we must raise an error. It doesn't make sense to retry writing on a non-blocking I/O error.

In this case, we must document that writelines() *must not* be used on non-blocking I/O (ex: non-blocking socket, pipe, whatever).
Date User Action Args
2016-02-05 08:51:44vstinnersetrecipients: + vstinner
2016-02-05 08:51:44vstinnersetmessageid: <>
2016-02-05 08:51:44vstinnerlinkissue26292 messages
2016-02-05 08:51:44vstinnercreate