Re: Discouraging use of sync APIs

[Jim Nelson <jim yorba org>]

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.

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.

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.

-- Jim

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