Gerd Knorr wrote:
> Bill Dirks wrote:
> > 2. There is no guaranteed way for the read()ing thread to
> > know where the frame boundaries are from the read() call
> > alone, especially if the data is compressed by a variable
> > length compression.
>
> A single read() call should never ever return data from more than
> one frame. The last of multiple partial reads will just return
> the remaining bytes of the current frame.
So if read() returns less than the number of bytes requested then that
is the end of the frame, but if read() returns the number of bytes
requested than that may or may not be the end of the frame. Still
doesn't work.
But we could make it work, e.g.:
Method A: Return value of 0 from read() is a frame boundary.
If a read() call returns the last bytes of a frame, then the
next read() call must return 0 bytes (no error, just a successful read
of 0 bytes). The next read() after that returns the first data of the
next frame.
Method B: Return value from read() not equal to the number of bytes
requested is a frame boundary.
If the number of bytes remaining is greater than the number
of bytes requested in the read(), then the driver must return the number
of bytes requested. If the number of bytes remaining is less than or
equal to requested, then the driver must return all remaining bytes. If
a read() call requests exactly the number of remaining bytes in the
frame, then the next read() must return 0 bytes.
Hmmm, I guess that's no worse than forcing read() to read a whole frame
at once. If something like the above will make life easier all around,
then we can do it.
Bill.
