4 ms·
> 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 t
by chillaxtian 10y ago
> 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?
- elktea 10y agoThreads are hard, basically.
- umanwizard 10y agoI 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
- azernik 10y agofsync() 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.
- quotemstr 10y agoBecause 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/StrictMode.html https://developer.android.com/reference/android/os/StrictMod...
- digi_owl 10y agoEven 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.