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 <rosslagerwall gmail com> wrote:On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode <halfline gmail com> wrote: Hi, On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall <philip tecnocode co uk> 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 desktop-devel-list gnome org https://mail.gnome.org/mailman/listinfo/desktop-devel-list_______________________________________________ desktop-devel-list mailing list desktop-devel-list gnome org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Attachment:
signature.asc
Description: This is a digitally signed message part