I am submitting this bug as Jarda wanted me to do it in issue #186744. Making P2 as the blocked issue is P2 as well.
I would prefer more closure like method, something like:
idleIO (Collection<? extends File> onFiles, Operation<File> closure). But feel free to implement it as you want.
Don't you rather want to have such method in parsing.api? It might cooperate in better way with other parsing tasks and parsing.api is already friend of masterfs, so it can use its existing idleIO.
It used to be an enhancement not issue. Sorry Jardo.
There is one reason why I don't want to make this standard API: Last release, when we started to use masterfs's idleIO, we run into few "deadlocks". Inside idleIO any I/O operation can take ages and as such any code can run really long. If that code holds any locks, other threads waiting for them get blocked as well.
We handled the mastefs.idleIO and slowRefresh problems as we could control both codes and gurantee that slowRefresh is lock-free. I think you can guarantee that for your usecase as well (thus I suggested to use the friend dependency with mastefs). But opening the API to public sounds too dangerous...
I will try, but I will need some help to find out what I should call in the master fs.
I will look in on Monday.
The right call is FileChangedManager.idleIO if it works for you, let me know and we'll move to someone into one of masterfs's friend packages (for now just make the FileChangedManager accessible).