Date: Sat, 17 Jun 2006 19:15:58 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Anish Mistry <mistry.7@osu.edu> Cc: freebsd-usb@freebsd.org Subject: Re: ugen partial write() amount Message-ID: <200606171916.00064.hselasky@c2i.net> In-Reply-To: <200606171154.50869.mistry.7@osu.edu> References: <200606161724.21722.mistry.7@osu.edu> <200606170950.10062.hselasky@c2i.net> <200606171154.50869.mistry.7@osu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 17 June 2006 17:54, Anish Mistry wrote: > On Saturday 17 June 2006 03:50, Hans Petter Selasky wrote: > > On Friday 16 June 2006 23:24, Anish Mistry wrote: > > > I'm trying to reliably recover from a write() timeout using > > > ugen. The problem that I'm having is that when using write() to > > > write data to an endpoint and the write times out there seems no > > > way to figure out the amount of that data that was actually > > > written. This is a problem when trying to write data to a > > > printer and the paper runs out. write() will timeout and you are > > > left with no way to figure out where to start sending data since > > > you don't know how much was received by the device before the > > > paper ran out. > > > It seems this could be possible by modifying the driver by > > > adding and ioctl that would allow you to call bulk transfer and > > > then return the number of bytes written. Is there a better way > > > of doing? > > > > What about disabling the timeout ? > > That works, the problem is that the write() will block causing the > controller application to be non-responsive and not report the > condition that caused the failure since it has blocked. I have some plans to make "ugen" asynchronous. Then you can use FIONBIO to set non-blocking mode, and poll the file descriptor. That is the solution I see. > My conclusion so far is that I would need to thread the writing logic > in the application, and then write my own timeout logic when I notice > that the write is blocking for longer than our time interval. At > least that is the option I can think of without modifying the driver. Yes. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606171916.00064.hselasky>