Discouraging use of sync APIs

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? 


* 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

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]