Re: Discouraging use of sync APIs

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

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.


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>
        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
        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
desktop-devel-list mailing list
desktop-devel-list gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

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