From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 09:00:39 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 4589737B401 for ; Thu, 22 May 2003 09:00:39 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE0643FA3 for ; Thu, 22 May 2003 09:00:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsUL-0000iH-00; Thu, 22 May 2003 09:00:18 -0700 Message-ID: <3ECCF3CC.CB425BD4@mindspring.com> Date: Thu, 22 May 2003 08:59:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Cornwall References: <20030521162339.GL21312@cicely12.cicely.de> <200305212245.h4LMjEGm006250@viper.evilrealms.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4920d6112372ec1aeed6dc9a7b81754e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de 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: Thu, 22 May 2003 16:00:39 -0000 Jay Cornwall wrote: > > 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. > > 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-based). > The problem arises from ugen blocking the entire process, rather than just > the thread which invoked the blocking read. It's the blocking I/O. The FreeBSD default libc_r utilizes a call-conversion scheduler that converts a blocking call into a non-blocking call plus a thread context switch in a user-space scheduler. If the conversion from a blocking call to a non-blocking call fails, then it will hang waiting for the operation to complete. For fd-based operations, the conversion is done on the basis of setting the O_NDELAY flag on the descriptor, and using normal fd system calls, which return -1 and an errno of "EAGAIN" when the operation would have blocked. The underlying code is then expected to have started the entirety of the requested operation, if it's a read. Short reads and writes, if a block would occur after a partial transfer, are wrappered to allow retry at a later point, until the entire request is satisfied. NB: The page fault path in the NBIO read-from-file case fails to start the operation and then return immediately. I personally consider this a bug, but all it effectively does is add latency, not hang, like you are experiencing. -- Terry