Synchronous I/O is never OK
Havoc Pennington: Synchronous I/O is never OK.

"If synchronous IO becomes a problem, it can be made asynchronous later." Tempting to imagine that some operations on local files are "fast enough" to implement with synchronous IO. "Premature optimization is the root of all evil," right?

Wishful thinking. Async vs. sync IO is not a performance issue (in fact synchronous IO can be faster). It is a structural or qualitative issue, a design issue. Sync IO is guilty until proven innocent.

My new rule is: any code that will be blocking during a user-interactive main loop must run in a known-short time. The task must be known short, not indefinite-but-often-short.

Local file access could be short, but is not known short. Another common culprit: synchronous D-Bus calls.

I've seen so many rewrites from synchronous to asynchronous IO over the years - it is almost 100% likely that anything blocking the main loop eventually comes to be seen as a bug. There's near-zero chance it's really OK to use those nice, easy-to-program blocking D-Bus calls, or that nice, simple g_file_get_contents(). Even the harmless looking g_file_test() can bite.

These APIs exist only to tempt you. They are the dark path.