This is just a guess, but it shows why such a feature is sensible and
in fact wanted:
With INN you can create a "channel feed", i.e. a pipe from innd into a
long-running daemon where innd will feed info about newly arriving
articles. When the child process exits, it gets respawned.
If the pipe has buffering behaviour, this may lose data in the case
where the child process exits before having read all available input.
E.g. innd writes info about 3 articles into the pipe, the child reads
one of them and then gets killed. This closes the pipe, the remaining
data is lost.
With the behavior you describe this does not happen: innd writes info
about one article into the pipe, then checks with select() for
availability. The pipe won't get ready for writing again until the
child has read this data block, and newly arriving article info will
remain buffered inside innd. When the child exits prematurely, the
worst thing that can happen is skipping _one_ article. Basically, the
pipe doesn't buffer when select() is used.
Of course INN is not the only application where this is useful, but
given that INN runs on a wide variety of platforms, I would expect it
to behave similarly on most of them.
olaf