On Wed, 2015-02-11 at 11:33 -0800, Jim Nelson wrote: > One of Philip's earlier suggestions was to print a console warning if > a sync call is used. That seems like overkill to me, but it does lead > to another possibility.
Emmanuele refined that to printing a warning if G_ENABLE_DIAGNOSTIC is enabled in the environment, which seems like a good idea to me. > Technically the issue is long synchronous calls blocking the event > loop, but in practice the problem is GTK+'s events being starved. > Perhaps a more feasible solution would be to issue a console warning > when a paint or resize event sits on the event loop for too long. Federico suggested there might already be such a warning, although grepping through the GTK+ code I can only find a warning about excessive re-layouts being requested (in gdkframeclockidle.c). I think a warning about delayed frames would be a good idea, though I’m not a GTK+ developer and they might have other ideas. One problem I see with this is that although it tells you there is a problem, it doesn’t let you know *what* is blocking the loop. You probably already knew there was a problem due to the UI freezing, in fact. > At the end of the day, async is something you design for, it doesn't > just happen (especially in straight-up imperative languages like C and > C++). No matter how many console warnings, documentation exclamation > marks, or API changes are made, it's all about getting developers to > treat I/O like event-driven programming. I know Jasper wishes apps > would only paint in the draw signal; getting everyone on-board with > pure-async code is a similar crusade. True, and there might not be a solution. I would like to check the possibilities though. Philip > On Wed, Feb 11, 2015 at 7:04 AM, Ross Lagerwall > <[email protected]> wrote: > > 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 > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
