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. 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? Not to mention of course that there's unavoidable synchronous disk IO before GLib is already loaded, in the kernel and dynamic linker.
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
