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

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

On Mon, May 31, 2010 at 5:09 PM, Emmanuele Bassi <ebassi gmail com> wrote:
On Mon, 2010-05-31 at 14:28 +0300, Владимир wrote:

> So I've dropped the gio monitor and started using inotify in the app
> I'm creating because of this (i.e. because I want end users to
> think/feel that my app is quick).

and yet you'll achieve the opposite as soon as you start getting
multiple events (that would be coalesced by GIO) and when you try to
handle them all you'll essentially perform a DoS on your UI.



gtk-devel-list mailing list
gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]