Re: Discouraging use of sync APIs

On Tue, 2015-02-10 at 15:48 +0100, Lennart Poettering wrote:
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

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

OK, that’s good to know. In any case, GMappedFile doesn’t have async
methods, so it’s a moot point.

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

I understand where you’re coming from; we should not be irritating
experienced developers. I completely agree.

What do you think of the proposal to use sync gstdio.h for
small/local/pseudo-file-system I/O and async GIO for all other I/O?

It might turn out that runtime checks are just not feasible, but in that
case I think we still need some way of solving the original problem:
that people are using sync calls and blocking up the main loop.


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]