From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 15:45:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB07D37B401 for ; Wed, 21 May 2003 15:45:24 -0700 (PDT) Received: from viper.evilrealms.net (evilrealms.demon.co.uk [62.49.12.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id D31C143F85 for ; Wed, 21 May 2003 15:45:23 -0700 (PDT) (envelope-from jay@viper.evilrealms.net) Received: from viper.evilrealms.net (jay@localhost [127.0.0.1]) by viper.evilrealms.net (8.12.8/8.12.8) with ESMTP id h4LMjEbh006251; Wed, 21 May 2003 23:45:14 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by viper.evilrealms.net (8.12.8/8.12.8/Submit) id h4LMjEGm006250; Wed, 21 May 2003 23:45:14 +0100 Message-Id: <200305212245.h4LMjEGm006250@viper.evilrealms.net> From: Jay Cornwall To: ticso@cicely.de Date: Wed, 21 May 2003 23:44:46 +0100 User-Agent: KMail/1.5.1 References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> In-Reply-To: <20030521162339.GL21312@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline cc: freebsd-hackers@freebsd.org Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:45:25 -0000 X-List-Received-Date: Wed, 21 May 2003 22:45:25 -0000 =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-----