Re: Discouraging use of sync APIs

[Lennart Poettering <mztabzr 0pointer de>]

On Tue, 10.02.15 13:59, Philip Withnall (philip tecnocode co uk) wrote:

> > 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... 
>
> The problem is that GIO can’t know which accesses are to small, local
> files, and which aren’t. It already optimises reads from pollable
> streams (sockets) by keeping them in the main thread and adding them
> into the main poll() call.

Well, but the developer frequently knows that. He knows that the
config file in ~/.config is not going to be more than a few K. And
that it hence is fine to access it synchronously...

> > Also, glib has wrappers for making mmaping available to programs, to
> > improve seldom-accessed sparse databases efficient, do you want to
> > prohibit that too?
>
> No, mmap() is clearly a tool for a different kind of problem. If you’re
> accessing an mmap()ed file, you need to be sure it’s local anyway, I
> think? GMappedFile doesn’t have async versions of its methods,
> presumably for this reason.

mmap() works pretty Ok these days over NFS. Concurrent access
doesn't. But as long as you just want to access something, it's
fine...

That said it's probably not a good idea to use mmap() for stuff below
$HOME...

> As above, how about making that line the distinction between calling
> functions from gstdio.h and using GIO? In the former case, you know
> you’re operating on local files. In the latter, you could be operating
> on files from the moon.

I'd always leave some freedom for the developers. It is certainly good
to document things and push people into the right directions, but I
think there are many cases where the developer should have every right
to prefer sync access for valid reasons, even from the main loop...

Lennart

-- 
Lennart Poettering, Red Hat