On Fri, Apr 22, 2011 at 01:31:02PM +0300, Eli Billauer wrote: > The overall package I'm working on is kind-of general purpose, and > it's the package's user who chooses how the hardware input behaves. > I can't know anything about the data flow behavior, and still, I > want the reads from the 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 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.
There are a couple of ways you could look at it. First, ask yourself is the package user more likely to treat this as a file or a socket? And if a file, is it a structured file or a certain size, or is it a file whose contents are not known in advance? Then make your read behave the same way a read on such a file or socket would behave. I don't like this option, personally, because it makes assumptions about the user. The second way is to just support both modes of operation. Check if you were opened with O_NONBLOCK. If yes, don't ever block -- you are allowed to return -EAGAIN if you would otherwise block. If you were not opened with O_NONBLOCK, then blocking is allowed, and you can wait until you have a full quantum of data to return at once. Just out of curiosity -- what does the hardware do? Cheers, Muli _______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux