On Thursday 15 June 2006 14:53, Suffield, David wrote: > > > If you are getting the timeout after the write(), you may be > > > losing data when you close(endpoint_fd) between retries. The > > > write() may timeout after writing a partial buffer. Then the > > > close() > > > > will kill any > > > > > remaining partial buffer. > > > > Yes, that is what seems to be happening. How should a timed > > out write > > be handled? > > Good question, can the write() return a timeout only if no bytes > were written? Nope.
> Otherwise there is no way to account for partial > writes with no accurate write-count. > > Linux had a similar problem, the usbfs did not return an accurate > write-count after a timeout. But, Linux has a lower level interface > that allows you to leave the urb queued so that you can inform the > user then comeback and retry the same urb. This allowed no bytes to > be lost during retries. > > Another suggestion, given you can set the timeout with the ioctl > the select() looks redundant. I would remove it. Ok. It seems that having a timeout on write() can't be trusted since here is no way to know the amount of data written. The only thing I can think of would to make hpiod thread the Write() so that when it does block we can create our own timeout logic by flagging when there is a pending write that has blocked. -- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/
pgp7keUGQ26rk.pgp
Description: PGP signature
_______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
