This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients benjamin.peterson, neologix, petri.lehtinen, pitrou, sbt, stutzbach
Date 2011-11-03.15:49:21
SpamBayes Score 3.6419177e-09
Marked as misclassified No
Message-id <>
> Wierdly, it looks like BlockingIO is not raised anywhere in the code
> for the C implementation of io.

That would explain why it isn't raised :)

This is a hairy issue: read(n) is documented as returning either n bytes or nothing. But what if less than n bytes are available non-blocking? Currently we return a partial read. readline() behaviour is especially problematic:

>>> fcntl.fcntl(r, fcntl.F_SETFL, os.O_NDELAY)
>>> rf = open(r, mode='rb')
>>> os.write(w, b'xy')
>>> os.write(w, b'xy')
>>> rf.readline()

We should probably raise BlockingIOError in these cases, but that complicates the implementation quite a bit: where do we buffer the partial data? The internal (fixed size) buffer might not be large enough.

write() is a bit simpler, since BlockingIOError has a "characters_written" attribute which is meant to inform you of the partial success: we can just reuse that. That said, BlockingIOError could grow a "partial_read" attribute containing the read result...

Of course, we may also question whether it's useful to use buffered I/O objects around non-blocking file descriptors; if you do non-blocking I/O, you generally want to be in control, which means not having any implicit buffer between you and the OS.

(this may be a topic for python-dev)
Date User Action Args
2011-11-03 15:49:22pitrousetrecipients: + pitrou, benjamin.peterson, stutzbach, neologix, sbt, petri.lehtinen
2011-11-03 15:49:22pitrousetmessageid: <>
2011-11-03 15:49:21pitroulinkissue13322 messages
2011-11-03 15:49:21pitroucreate