Hacker News Reader

Comment by chillaxtian | Hacker News Reader

> I suppose it's understandable... nobody should ever be blocking GUI animations on fsync, much less two of them in a row, but here we are.

this is the thing that confused me.. why are apps doing disk i/o on the GUI thread?

View on HN

I think lots of stuff causes disk I/O that you might not even be aware of.

For example, on iOS, +[CLLocationManager authorizationStatus] (checking if the app is allowed to use location or not) has to read a file [1]. Almost no app developers are aware of this.

[1] I've been told this by guys who worked full-time on location stuff, but I haven't verified it myself and can't find it in docs, so take it with a grain of salt

fsync() in particular is usually only called on (well, after) disk writes though - I can see that being involved in all kinds of system API calls too, but hopefully the system makers would be savvy enough to use an actual write barrier instead of being fsync-happy.

Because they don't care enough not to. There are even developer tools to help applications not do work on the UI thread: https://developer.android.com/reference/android/os/StrictMod...

Threads are hard, basically.

Even if they don't, the kernel will likely drop everything to get that fsync out of the way. So a fsync happy app that is doing a file write in the background can cause the whole UI to lag because the kernel is busy dealing with said fsync call.

Reply on news.ycombinator.com