Re: inotify back end for tail -f on linux

[Jim Meyering]

shawn wrote:
> Perhaps this has already been discussed

Thanks for the suggestion.
Yes, this has been discussed, e.g., in

    http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15031/focus=15052

I like the idea and outlined how I'd like to see this functionality
make it's way into the coreutils.

In the message above, I suggested this:

  Prototype a new tail-like tool that requires Linux inotify support.
  I'd do it in perl, maybe using the Linux::Inotify2 module.  There may
  be better; I haven't looked in a long time.  It's far easier to prototype
  something like that in a scripting language than in C.  To be useful,
  it'll need at least some of the options iwatch has, e.g., for filtering.

  Then, once everyone thinks the feature set is complete,
  rewrite it in C.


> tail -f polls and is highly inefficient

Can you describe a situation in which it is "highly" inefficient?
afaik, it becomes inefficient only when there are many files
or when you choose a polling interval that is much smaller
than the default.

> when there exists event
> notification such as inotify. It would be nice if this could be added in
> a way that does not break any systems, even if compiled for Linux and
> the Linux kernel it runs on does not have inotify. If inotify does not
> work it would fall back to polling.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423886