Re: Is it a bug in Gio::FileMonitor?
- From: Владимир <cl333r gmail com>
- To: Alexander Larsson <alexl redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Is it a bug in Gio::FileMonitor?
- Date: Thu, 10 Jun 2010 04:23:42 +0300
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>
Yes, because you didn't select for file change events, only creation and
On Wed, 2010-06-02 at 04:26 +0300, Владимир wrote:
> On Tue, Jun 1, 2010 at 12:57 PM, Alexander Larsson <alexl redhat com
> 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
> 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.
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.
I don't think gio is perfect, the inotify backend in particular is kinda
> 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.
crufty and ugly. If a hard dependency on inotify works for you, by all
means go for it!
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!
] [Thread Prev