On Fri, 2015-02-13 at 04:52 -0500, Colin Walters wrote: > On Wed, Feb 11, 2015, at 02:33 PM, 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. > > > > > > 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. > > > > Agree with this. > > > Also, this kind of warning should really only occur after the first > paint. Or we could *try* changing it to happen only after the first > main context iteration, but I suspect that would still be too > annoying.
Only warning after the first main context iteration would allow things
like:
g_file_read() /* sync startup call to load config */
…
gtk_main()
> Changing glib to spew errors for sync IO unconditionally during app
> startup or hiding the sync API docs are just an obviously, totally
> ridiculous nonstarters - particularly console apps. How is it even a
> topic of discussion?
The suggestion has since been refined to be conditional on the I/O
taking ‘a while’, being in the main thread, and G_ENABLE_DIAGNOSTICS
being enabled.
See: https://bugzilla.gnome.org/show_bug.cgi?id=744458
It was originally a strawman idea, precisely for the reason of gauging
how ridiculous people thought it was. The idea of unconditional warnings
is ridiculous.
> Not to mention of course that there's unavoidable synchronous disk IO
> before GLib is already loaded, in the kernel and dynamic linker.
But that doesn’t block the main loop, so isn’t causing interactivity
problems and we don’t care.
Philip
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
