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: Wed, 2 Jun 2010 04:26:52 +0300
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]