[Python-3000] iostack and sock2

Ronald Oussoren ronaldoussoren at mac.com
Tue Jun 6 12:06:19 CEST 2006

On 6-jun-2006, at 11:51, Nick Coghlan wrote:

> Greg Ewing wrote:
>> tomer filiba wrote:
>>> okay, i give up on read(n) returning n bytes.
>> An idea I had about this some time ago was that read()
>> could be callable with two arguments:
>>    f.read(min_bytes, max_bytes)
>> The two variations we're considering would then be special
>> cases of this:
>>    f.read(0, num_bytes)         # current read() behaviour
>>    f.read(num_bytes, num_bytes) # record-oriented read() behaviour
> You can even makes this backwards compatible by having the  
> min_bytes argument
> default to 0. (whether or not the order of the two arguments should be
> reversed in that case is debatable, though)

I'm slighly worried about this thread. Async I/O and "read exactly N  
bytes" don't really match up. I don't know about the other  
mechanisms, but at least with select and poll when the system says  
you can read from a file descriptor you're only guaranteed that one  
call to read(2)/recv(2)/... won't block. The implementation of a  
python read method that returns exactly the number of bytes that you  
requested will have to call the read system call in a loop and hence  
might block.

There's also to issue of error handling: what happens when the first  
call to the read system call doesn't return enough data and the  
second call fails? Does this raise an exception  (I suppose it does)  
and if so, what happens with the data that was returned by the first  
call to the read system call?

All in all I'm not too thrilled by having this behaviour. It is handy  
when implementing record-oriented I/O, but not when doing line- 
oriented I/O.

BTW. Has anyone looked at the consequences of the new iostack and  
sock2 for libraries like Twisted?


More information about the Python-3000 mailing list