Re: Is it a bug in Gio::FileMonitor?

[Sven Herzberg <herzi gnome-de org>]

Hi,

Am Mittwoch, den 02.06.2010, 04:26 +0300 schrieb Владимир:
> 
> On Tue, Jun 1, 2010 at 12:57 PM, Alexander Larsson <alexl redhat com>
> wrote:
>         On Mon, 2010-05-31 at 17:36 +0300, Владимир wrote:
>         
>         
>         There is nothing "server" about change notification
>         coalesceing. If any
>         app downloads or copies a file you'll get a change event for
>         every call
>         to write() (if you read all events). This can easily be in the
>         hundreds
>         a second for the entire duration of the download/copy. So, any
>         UI that
>         tries to handle every change will more or less lock up.
>         
> 
> You're talking about gio, I wanted to see what inotify would do in
> same circumstances: 
> 
> 
> I started inotify to listen to all the events on my desktop folder,
> then I took a large zip file (about 500MB) and started copying it to
> the desktop folder. There was no "hundreds a second" events, just 4
> (four) events: IN_CREATE, then IN_OPEN, then IN_CLOSE_WRITE and
> finally (as the copy finished) IN_ATTRIB.
> 
> So inotify doesn't suffer from the Armageddon you describe, also it's
> fast. How come gio would be doomed/overworked in such a scenario and
> it's slow at reporting even 1 file change quickly.
> 
> Sorry I don't mean to be harsh but after these conversations I'm
> really starting to like inotify a lot more and disliking gio.

For one thing: Please don't try to tell people that inotify is better
than GIO. GIO can use inotify as a backend [1] on GNU/Linux and _has_ to
use other backends on other platforms (just like Alex already
mentioned).

For the other: try to run something like this in several processes
(10-20) in parallel on your downloaded file (preferably on a tmpfs to
make sure the hard drive won't end up being the bottleneck at some
point):
$ split --bytes=4 $YOUR_DOWNLOADED_FILE
inotify should pretty quickly make your monitoring application cough up.

[1]http://git.gnome.org/browse/glib/tree/configure.in#n1626

Regards,
  Sven