Date: Sat, 17 Jun 2006 13:28:15 -0400 From: Anish Mistry <mistry.7@osu.edu> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: ugen partial write() amount Message-ID: <200606171328.24960.mistry.7@osu.edu> In-Reply-To: <200606171916.00064.hselasky@c2i.net> References: <200606161724.21722.mistry.7@osu.edu> <200606171154.50869.mistry.7@osu.edu> <200606171916.00064.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1309124.JPdP4M1zSc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 17 June 2006 13:15, Hans Petter Selasky wrote: > 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. Most excellent. =20 > > > 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. I'll go with this approach. =2D-=20 Anish Mistry --nextPart1309124.JPdP4M1zSc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBElDu4xqA5ziudZT0RAm7gAJ9vNERXpSMfEuGELRuCoaPCrTPNnwCgwdcY uvGlcdW/w9UbQHFR8zA8Umw= =LrA/ -----END PGP SIGNATURE----- --nextPart1309124.JPdP4M1zSc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606171328.24960.mistry.7>