USB bulk read & pthreads

Bernd Walter ticso at cicely8.cicely.de
Wed May 21 16:00:30 PDT 2003


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 at bwct.de                                  info at bwct.de



More information about the freebsd-hackers mailing list