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

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

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.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list