From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 21:45:33 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 8AB4837B401 for ; Tue, 20 May 2003 21:45:33 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0933A43F75 for ; Tue, 20 May 2003 21:45:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-uinj8tt.dialup.mindspring.com ([165.121.163.189] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ILTg-0007G2-00; Tue, 20 May 2003 21:45:25 -0700 Message-ID: <3ECB041D.4FE961D@mindspring.com> Date: Tue, 20 May 2003 21:44:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47eb7876021f40d912a895b9f5f43022ca8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Jay Cornwall 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 04:45:33 -0000 Julian Elischer wrote: > On Wed, 21 May 2003, Jay Cornwall wrote: > > The problem seems to be a result of reading from a USB endpoint file > > descriptor, which invokes tsleep() within the kernel > > (/sys/dev/usb/usbdi_util.c:432) while it waits for data to read. This has the > > effect of blocking the whole process, rather than just the thread which > > called the read. > > You should load teh "linuxthreads" port > and link with that.. > > under 5.x you will be able to use the native threads (we will have > several to choose from :-) > > under 4.x (I presume that's what you are using) the threading is all in > one process and if a device decides to return "data waiting" in select() > but keeps the reader waiting, it will block the entire process. Or it's a bug in the USB driver, not honoring non-blocking I/O. -- Terry