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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
