Date: Wed, 21 May 2003 23:44:46 +0100 From: Jay Cornwall <jay@evilrealms.net> To: ticso@cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: USB bulk read & pthreads Message-ID: <200305212245.h4LMjEGm006250@viper.evilrealms.net> In-Reply-To: <20030521162339.GL21312@cicely12.cicely.de> References: <Pine.BSF.4.21.0305201638000.22764-100000@InterJet.elischer.org> <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 21 May 2003 17:23 pm, you wrote: > > Or it's a bug in the USB driver, not honoring non-blocking I/O. > ugen(4) does not support non-blocking I/O like most other driver also do > not. > > I don't count it as a bug as noone ever told that it does. > It's even documented in ugen(4): > The bulk transfer mode can be in or out depending on the endpoint. = To > perform I/O on a bulk endpoint read(2) and write(2) should be used.= =20 > All I/O operations on a bulk endpoint are unbuffered. > non-blocking requires buffered I/O. Yes, blocking I/O isn't a problem for this application (as it's thread-base= d). The problem arises from ugen blocking the entire process, rather than j= ust the thread which invoked the blocking read. This isn't consistent with normal blocking read behaviour AFAIK, and I just= wondered if there was a reason it was implemented in this way, or if it wa= s simply an oversight on the use of threading with the ugen device. But thanks for your comments, all are welcome. :) Cheers, Jay =2D --=20 http://www.evilrealms.net/ - Systems Administrator & Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+zAFgfJLn3O/2GbERArPzAKCAUyHVaVmN7PK38x3v0LJA5mkiqwCfQdOI mzY9GtSfHsk6lzXEm1kASsw=3D =3DBAhJ =2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305212245.h4LMjEGm006250>