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
<rosslagerw...@gmail.com> wrote:
On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode <halfl...@gmail.com>
wrote:
Hi,
On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall
<phi...@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
