On Mon, 09.02.15 10:47, Philip Withnall ([email protected]) 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
