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

[Alexander Larsson <alexl redhat com>]

On Mon, 2010-05-31 at 17:36 +0300, Владимир wrote:
> Thanks for your attention.
> I agree with you in the case of servers. But I'm talking about the
> desktop (sorry forgotten to mention it). I hope you'll agree with me
> that for a desktop it's a very (very!) unlikely such a situation which
> would happen (if at all) only under very heavy stress. I think common
> sense implies that a "normal" desktop user would rather want a quick
> system that feels and acts quickly (roughly saying) 99.9999% of the
> time rather than constantly "feel and act" slowly but manage to
> properly treat that (roughly saying) one in a million situation (if at
> all). By the way, I think that because of this, the "delete" sometimes
> doesn't work in Nautilus (seems to be lost) but don't quote me on this
> as I don't know if this particular issue is related to gio.

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.

Nautilus tracks delete from nautilus itself internally, so does not
depend on inotify for that. (It does use it to find deletes from other
apps though.) So, if there is a bug here its more likely some internal
issue.

> I hope you'll agree that because of this there should be some change
> (in gio), at least let the developer customize the timing or so. On a
> somewhat different note, isn't set_rate_limit() designed to solve this
> timing issue? And if so, am I right in asserting that it's not
> working?

Yeah, we could probably spend some time tweaking the timings. Rate
limiting isn't exactly the same as latency, but it sort of implies some
kind of bound on the delay, so we should try to propagate that into the
inotify backend.