Message7095

Author pjenvey
Recipients amak, fwierzbicki, jeff250, pjenvey, ssweens
Date 2012-05-15.21:34:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1337117687.79.0.547317302871.issue1754@psf.upfronthosting.co.za>
In-reply-to
Content
InputStream.read actually *does* block.

Our file wrapper reads this InputStream via an nio Channel wrapper. It looks like this wrapper will only make one read (and thus not block) if the wrapped InputStream.available() returns 0.

The wrapper reads in 8192 byte sized chunks. I suppose this means the bug would be avoided entirely if Content-Length was smaller than that?

Python 2 *and* 3's socket.makefile definitely block. Since we're more based on Python 3's impl here, the fix should be based on its behavior.

So Python 3's SocketIO (the basis for Python 3's socket.makefile) seems to be the place that does the actual blocking read (in its readinto method). That method apparently specially handles blocking and non-blocking modes. We need to be consider that along with the strange behavior of the nio Channel wrapper for our fix
History
Date User Action Args
2012-05-15 21:34:47pjenveysetmessageid: <1337117687.79.0.547317302871.issue1754@psf.upfronthosting.co.za>
2012-05-15 21:34:47pjenveysetrecipients: + pjenvey, fwierzbicki, amak, jeff250, ssweens
2012-05-15 21:34:47pjenveylinkissue1754 messages
2012-05-15 21:34:47pjenveycreate