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
Attachment:
signature.asc
Description: This is a digitally signed message part