Re: Discouraging use of sync APIs

[Federico Mena Quintero <federico gnome org>]

On Mon, 2015-02-09 at 12:53 +0000, Emmanuele Bassi wrote:

> I do agree with Philip's proposal of warning if the sync API is called
> inside the default main context, even if there's the obvious issue of
> console-only code that still uses a main loop, but does not have
> interactivity issues.
>
> maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages;
> after all, we're already using it for deprecated properties and
> signals.

Having that kind of diagnostic (i.e. a developers-only tool) would be
nice.  Paired with Bastien's suggestion:
> and would rather it threw an error if that sync call took too long
> instead.

Didn't we have something like that for GTK+'s frame clock?

I guess it boils down to really looking at where and why those sync
calls are happening.  For example:

* I turn on my machine and start my session.  Gnome-shell brings up an
empty desktop.  I *can't do anything* until I pop up the Activities, but
when I do that, gnome-shell takes a little to read all the icons
or .desktop files for the applications, and there is a noticeable delay.
At startup, it could read those asynchronously so that they would be
ready when I bring up the Activities for the first time.

* Gnome-shell takes noticeably longer to respond at startup if the VPN
is not started yet *and* my /etc/resolv.conf was left with a DNS server
that is only accessible through the VPN.  I don't know if gnome-shell
actually needs to resolve a host name, or if it's waiting for
NetworkManager for something, or what.

The first case is about making the best use of time; the second one is
probably just a bug, or a bad API that forces gnome-shell to wait.  I
don't think you can just say, "sync calls bad" all the time :)

  Federico

-- 
GPG fingerprint - RSA 4096:
263F 590F 7E0F E1CB 3EA2  74B0 1676 37EB 6FB8 DCCE