You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following async file I/O methods should never be called -- they create undue overhead in the async wiring required to accomplish them, and their corresponding sync versions require minimal overhead.
File.lastModified()
FileSystemEntity.isDirectory()
FileSystemEntity.isFile()
FileSystemEntity.isLink()
FileSystemEntity.type()
FileSystemEntity.exists()
FileSystemEntity.stat()
We should convert all existing uses of these methods (in flutter_tools - we don't use them in the framework) to use the sync versions, and we should add a test that ensures we don't re-introduce them. Over time, if any other such methods come up, we can just add them to this method blacklist.
I was running the linter over some code recently and ran into this lint.
I'm not convinced this is actually a good idea. Won't these methods risk entirely locking up the app when run on networked file systems or file systems with bad disks?
They'll lock up the app to the extent that the syscalls hang (whereas with async, we could add a timeout). So bottom-line: yes.
That said, for local disk access, what spawned this issue is that @johnmccutchan and I were seeing real slowdowns in the Flutter tool due to the use of these async ops (in loops, for instance) -- where converting to sync calls saved a few hundred milliseconds.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
tvolkert commentedon Dec 6, 2016
/cc @danrubel
Hixie commentedon Dec 6, 2016
We should definitely either always use one or always use the other.
Having said that, some people use NFS, and NFS can take a long time to return from these calls...
danrubel commentedon Dec 8, 2016
Landed a new lint to discourage use of specific async i/o methods
johnmccutchan commentedon Dec 8, 2016
@danrubel nice!
Update analysis options (#8203)
Hixie commentedon Jan 8, 2018
I was running the linter over some code recently and ran into this lint.
I'm not convinced this is actually a good idea. Won't these methods risk entirely locking up the app when run on networked file systems or file systems with bad disks?
tvolkert commentedon Jan 8, 2018
They'll lock up the app to the extent that the syscalls hang (whereas with async, we could add a timeout). So bottom-line: yes.
That said, for local disk access, what spawned this issue is that @johnmccutchan and I were seeing real slowdowns in the Flutter tool due to the use of these async ops (in loops, for instance) -- where converting to sync calls saved a few hundred milliseconds.
Hixie commentedon Jan 8, 2018
A difficult trade-off. We definitely have users on NFS, but we also have many users on local disks...
github-actions commentedon Aug 8, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.