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

[Владимир <cl333r gmail com>]

I said I listened to "all the events", not just some, in particular IN_ATTRIB stands for "File's metadata (inode or xattr) was changed.".
That is, I used IN_ALL_EVENTS which stands for "Bitwise OR of all events.".

I also think it's sad that instead of a reaction like "hey, he's got a point, this issue does make apps feel sluggish so we should investigate into it, after all even Java (7) which is also cross-platform doesn't suffer from this", there's instead quite the opposite reaction to not improve, like "if we do this, a bad side effect will happen (and if you prove we're wrong about it we'll find another noble excuse) or just say nothing is perfect".

And thanks, I already went for inotify because clients/users want quality, not noble excuses.

On Wed, Jun 2, 2010 at 2:26 PM, Alexander Larsson <alexl redhat com> wrote:

On Wed, 2010-06-02 at 04:26 +0300, Владимир wrote:
>
> 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.

Yes, because you didn't select for file change events, only creation and
close-write. This means you won't get any updates to a file that changes
but is not closed. For instance a log file or just a long download.

> 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.

I don't think gio is perfect, the inotify backend in particular is kinda
crufty and ugly. If a hard dependency on inotify works for you, by all
means go for it!

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc
      alexl redhat com            alexander larsson gmail com

He's an underprivileged alcoholic dwarf with a winning smile and a way with
the ladies. She's a sarcastic junkie pearl diver on the trail of a serial
killer. They fight crime!