Closed jbmorley closed 2 years ago
I've made a couple of changes to address some of these issues:
DirectoryMonitor
which guarantees that monitoring has started when a call to DirectoryMonitor.start
returns; it doesn't offer much on its own, but should allow us to assemble the directory monitors in queue_updateSubDirectoryMonitors
recursively, in a way that guarantees we don't miss changesConcurrentQueue
and consuming these in the update operationNote that the second change is also guaranteed to always notify newly added observers once observation has started, as observer notification has been moved into queue_updateSubDirectoryMonitors
(called during initial setup). Once 1. is resolved by setting up recursive observers more systematically, we should be able to guarantee that no change is missed following a call to add an observer.
I've also added a 0.1s delay when scheduling queue_updateSubDirectoryMonitors
(see b1255be0ad34addd53d0dd8bb2a65bcb76308901) to mitigate the worst effects of rapid file writes and directory changes.
Current status:
DirectoryMonitor
instances to ensure we don't miss changes.RecursiveDirectoryMonitor
should be good enough to address these issues; there are still secondary observers that do work as a result of a change (e.g., Directory
, and ProgramDetector
) which might cause us problems and necessitate their own rate limits. In that case, it probably makes sense to pull in something similar to BRURateLimiter
(see https://github.com/jbmorley/BromiumCoreUtils/blob/master/BromiumCoreUtils/BRURateLimiter.m)Is it necessary to add a rate limiter to ProgramDetector
and Directory
?
Graceful failures have been added in b781db2aceb655c6ef55b72d23f8732d8018c595, leaving just 1. to be completed to bring this directory monitoring approach up to about the best we can manage.
As of 5e29a464abb74c5e847fa2b93bb8676438ef001a, the remaining start-up race conditions should have been addressed (🤞🏻). This just leaves the question of whether we want to individually rate limit updates in ProgramDetector
, Directory
, and UbiquitousDownloader
.
Closing as done. We've put in significant performance improvements and I think the observer now seems to be pretty robust.
DirectoryMonitor
for the directory in which the new directory is created 😮💨). This can lead to programs failing to detect during install as there are a number of nested directories created in quick succession. The specific install-time issue is being tracked as #136, and it's likely that we'll fix that by using a dedicated notification at install time to guarantee that new files are never missed.RecursiveDirectoryMonitor
has a shared instance which is able to share the monitoring across clients which does go some way to mitigating this, but right now it's still possible to crash the app if you add too big a directory, with no recovery mechanism. This was originally being tracked in #130 (where there's some discussion and ideas), but I thought it would be useful to pull the issues together to get a real sense of the monitoring situation.