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 fine... That said it's probably not a good idea to use mmap() for stuff below $HOME...
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. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part