Hi all,
From some feedback from real-world users of GLib/GIO (see the ‘Feedback
from downstreams’ thread), and just from looking at our own code in
GNOME, it seems that people persistently use sync versions of APIs in
the main thread when they should be using async ones.*
How can we fix this?
I guess there are two approaches: making async APIs easier to use; and
discouraging use of sync ones. I think the GAsyncResult framework we’ve
got is pretty good, and I can’t think of a way to simplify it.
(Suggestions welcome.)
For discouraging use of sync APIs, I have two strawman ideas:
1. Hide the sync APIs in the documentation index, and only allow their
documentation to be viewed from a link from the async versions. That
would potentially fix the case where someone searches for ‘file
read’, finds g_file_read() as the first result, and never looks as
far as g_file_read_async().
2. A bit more extreme: emit a warning every time a sync API is run in
the main thread (but not if it’s run in a worker thread). This
should capture precisely the situations we want to avoid (sync calls
blocking the main thread’s loop), but is a bit ugly, and people
don’t always check their code for runtime warnings.
2b. Similarly, we could potentially statically analyse which threads
each sync function could potentially be called from, and warn if
sync functions are potentially called from the main thread. But I
haven’t put much thought into how such an analysis would work, and
it wouldn’t be trivial to implement.
What are people’s thoughts?
Philip
* There are definitely legitimate uses of sync APIs, but not from the
main thread, ignoring trivial command line utilities (and even then, if
they want to handle signals properly, they should be running a main
loop).
Attachment:
signature.asc
Description: This is a digitally signed message part