Re: Potential problem with reading data from usb devices with ugen(4)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I really should refrain from asking questions until I have a
better understanding of what I'm seeing.  It turns out the problem is a
little different than I initially thought.

With the file descriptors set to non-blocking mode with read ahead and
write behind turned on, if a write gets blocked, it won't retry the
transfer until a read gets called to reactivate it.  What's happening is
that if two writes get called in succession without an intermediary read,
and the first write failed to transfer to the device on the first go round,
the second write gets concatinated to the first before the transfer is
tried again on the second write call.  I'm sure this is a bug which I've
now squashed, or, at least, am in the process of squashing.

	Now, I'm seeing another problem which I don't entirely understand, but
for which I have a question.  It looks like the read ahead and write behind
code use the same buffer for reading and writing respectively.  Was this
decision intentional?  If so, does anyone remember what the rationale was?
I get that you can't read and write to the device itself simultaneously,
but given threads and multiprocessing capabilities of today, it's
conceivable that buffers could be filling and draining from or to user
space simultaneously, causing collisions to happen in this one buffer.  I'm
thinking of separating the read and write buffers to prevent this
potential.   Any reason I shouldn't do that?

-thanks
-Brian

On Nov 7,  6:47am, Greg Troxel wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} --=-=-=
} Content-Type: text/plain
} 
} 
} Brian Buhrow <buhrow%nfbcal.org@localhost> writes:
} 
} > 	Hello.  Another question  about the read ahead and write behind code
} > in ugen(4).  It seems that if a write call comes in with a block of data,
} > and a second write call comes in with a second block of data before the
} > first block of data has been written to the USB device, the two blocks of
} > data get concatinated into one USB xfer to the device.  Questions:
} 
} I have no recollection of intending that it work this way.   The point
} was to avoid the latency of write(2) followed by an xfrer followed by
} notifying the user process followed by another write(2), as with a USRP
} (1st gen) without the RAWB code, we were only able to operate at 16 MB/s
} transfer rates rather than 32 MB/s.  (All details slightly fuzzy; this
} was 2005/2006.)
} 
} It could be that we knew the USRP didn't care about bigger blocks (since
} it's a stream of samples).  Or that we never made a 3rd write call until
} the 1st one finished.
} 
} --=-=-=
} Content-Type: application/pgp-signature; name="signature.asc"
} 
} -----BEGIN PGP SIGNATURE-----
} Version: GnuPG v1
} 
} iEYEARECAAYFAlY95NYACgkQ+vesoDJhHiX7BgCePwls/akMZ80pwlGZGu6zVd4M
} yg0AoJ1CW0EUET2f9hgE9+Xynb96v2m9
} =OT3B
} -----END PGP SIGNATURE-----
} --=-=-=--
>-- End of excerpt from Greg Troxel