On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode <[email protected]> wrote: > Hi, > > On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall <[email protected]> > wrote: >> It might turn out that runtime checks are just not feasible, but in that >> case I think we still need some way of solving the original problem: >> that people are using sync calls and blocking up the main loop. > I'm all for discouraging sync use in the main thread after the > application is up, but > are stalled applications actually a wide spread problem? I don't > really remember any > apps I use regularly locking up (except for maybe hexchat when connecting to > my > irc proxy). Granted, it's harder to notice these days now that we > have a compositor > and applications don't need to redraw after getting uncovered, so it > could be it's > happening more than is obvious. But, I just wonder if we really need > to do anything. > It seems like the bad/obvious cases would get bug reports and fixes > pretty quickly, > and so the problem should regulate itself. >
There are quite often gvfs or Nautilus bug reports that say "network mount causes desktop to slow down". I tracked it down to some gnome-shell extension which somehow does sync calls to the remote fs which makes everything crawl. In general though I think severe warnings on the documentation for each sync call is better than runtime warnings or compile-time warnings. Ross _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
