Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 May 2003 01:00:11 +0200
From:      Bernd Walter <ticso@cicely8.cicely.de>
To:        Jay Cornwall <jay@evilrealms.net>
Cc:        ticso@cicely.de
Subject:   Re: USB bulk read & pthreads
Message-ID:  <20030521230010.GD30678@cicely8.cicely.de>
In-Reply-To: <200305212245.h4LMjEGm006250@viper.evilrealms.net>
References:  <Pine.BSF.4.21.0305201638000.22764-100000@InterJet.elischer.org> <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> <200305212245.h4LMjEGm006250@viper.evilrealms.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 21, 2003 at 11:44:46PM +0100, Jay Cornwall wrote:
> 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. 
> > 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 is a problem as non-blocking I/O is the only way for a userland
scheduler to handle I/O based wait conditions.
The scheduler silently converts blocking I/O to non blocking so
it can reschedule instead of block.
If instead the kernel blocks then the userland scheduler is just out of
business.

> 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 was simply an oversight on the use of threading with the ugen device.

Both parts are handled that way for good reasons.
As others already wrote - you have to use a thread implementation
which is not entirely based on userland scheduling.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso@bwct.de                                  info@bwct.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030521230010.GD30678>