USB bulk read & pthreads

[Bernd Walter]

On Tue, May 20, 2003 at 09:44:13PM -0700, Terry Lambert wrote:
> 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.

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.

The device gets regulary polled if someone has an outstanding transfer.
Implementing nonblocking I/O would require always to have an
outstanding read for open devices - similar is done in ucom(4).

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