[Haifux] Implementing read() like UNIX guys like it

[Nadav Har'El]

On Fri, Apr 22, 2011, Eli Billauer wrote about "[Haifux] Implementing read() like UNIX guys like it":
> Now the dilemma: Suppose that the read() method was called with a requested 
> byte count of 512. The driver checks its internal buffer, and discovers 
> that it can supply 10 bytes right away and return, or it can block and wait 
> until it has all the 512, and return only when the request is completed 
> fully. The hardware data source is streaming, with no guarantee if and when 
> this data will arrive.
> 
> Or, it can try waiting a little (what is "a little"?), and then time out, 
> returning with whatever it has got (Ã  la TCP/IP).
> 
> I suppose all three possibilities are legal. The question is what will work 
> most naturally.

>From what I understand, your device resembles a pipe - a stream of bytes that
come from some external source, and you have no idea when they will come.

In that case, the most "natural" behavior is the behavior of regular Unix
pipes, i.e., when some data is available, a read(2) returns with possibly
a lower number of bytes read than requested. This basically means that your
options #1 (return what you have) and #3 ("wait a little") are recommended -
but option #1 seems the easiest to implement and I'd therefore recommend
against the more complex #3 unless you're sure this will give you some sort
of performance win (I don't know how much performance tweaking actually
matters in your use-case).

Option #2 (blocking until all requested bytes are available) is bad, and
un-Unix-like: It means that a program, e.g., cat(1), which uses stdio
(fgets, scanf, etc.) may issue a read(fd, buf, BUFSIZE) and then block
until BUFSIZE bytes are available; This may make sense for files on hard
disks, but sort of buffering is unexpected on pipes, and probably on your
device as well.

> relevant file descriptor to behave as one would expect. For example, a user 
> may choose to read from the file descriptor with scanf or fgets. The user 
> would expect these to return whenever sufficient data has been fed into the 

This is why I recommeneded against option #2.

> hardware side. On the other hand, if the data comes slowly into hardware, 
> read()'s will return with one byte at a time, which is maybe not desirable 
> either.

If the device so slow that reads return one byte at a time, the performance
impact of reading them one by one is probably not important. On a quick
device, by the time you next read() from it probably more than one character
will be ready. This will give you the best of both worlds: Low latency when
the device is slow, and high throughput when it is fast.

-- 
Nadav Har'El                        |      Tuesday, Apr 26 2011, 22 Nisan 5771
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |"Outlook not so good." Wow! That magic 8-
http://nadav.harel.org.il           |ball knows everything! So, what about IE?