Re: Discouraging use of sync APIs

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 09.02.15 10:47, Philip Withnall (philip tecnocode co uk) wrote:

> 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.*

[...]

> * 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).

Uh, oh. This is really oversimplifying things. Note that on Linux disk
IO is generally synchronous, and it's good that way, and you cannot
really avoid it. I mean, never forget that your executable and its
shared libraries are all mapped into memory and access to their pages
results in synchronous IO. Even if you wanted you couldn't make that
async... 

I am pretty sure if you do async IO like gio does for every single
file access you'll just complicate your program and make it
substantially slower. For small files normal, synchronous disk access
is a ton faster than dispatching things to background threads, and
back... 

Also, glib has wrappers for making mmaping available to programs, to
improve seldom-accessed sparse databases efficient, do you want to
prohibit that too?

Moreover on Linux file systems like /proc, /sys, /run, /tmp are known
to not be backed by slow physical IO, hence its really pointless
accessing them via async IO...

Then, during start-up of your app, when you need to read some config
file or so before you can do your first steps, why bother with async
stuff? You need to wait for for reading/parsing that file anyway
before you can proceed?

I think async IO is great, but it's definitely not the magic wand to
apply to every single bit of IO. Linux synchronous IO is pretty damn
fast, it's hard to optimize on that from userspace...

Hence, my recommendation would be to draw the line somewhere between:
"potentially unbounded user payload" data and "configuration/control"
data. For the former it would be wise to encourage async IO but for
the latter certainly not. If you follow what I want to say...

Lennart

-- 
Lennart Poettering, Red Hat