On Fri, Dec 28, 2007 at 07:50:37PM -0500, Greg Troxel wrote: >1) On a read system call, if there is any data already read, return it. >If not, invoke a read bulk transfer, and if it completes very quickly >return the data. If not, return EWOULDBLOCK. This perhaps fudges a bit >on non-blocking vs fast. > >2) On open, start a read transfer, and as each transfer completes, if >there is room in the input buffer, start a new one. On a read system >call, return whatever data is already in the buffer (and therefore start >a read transfer if space is newly freed).
Option 1 would seem to be the safest and easiest. >Besides non-blocking reads, there's the issue of select/poll for read. >To make this work, I think approach #2 is needed, because if no read >transfer has been done, there's no way to know if there's data. An alternative approach would be to have poll/select-for-read initiate a read transfer if there is no data available (ie if the poll/select would block). Note that, at present, ulpt(4) on FreeBSD doesn't support any read buffering. I've been bitten by this and there's a patch in PR usb/91538 to implement read buffering. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpFUCGnwAnTW.pgp
Description: PGP signature
