> sre 15.05.2019, at 13.32, Thomas Tempelmann wrote: > > Without knowing the particulars about sandboxing, I wonder why you originally > wanted to use multiple streams anyway. I had thought it's obvious that using > multiple streams for watching multiple locations would be rather inefficient > compared to having only one watcher for "/", and then filter the items > yourself
It may be obvious to you, but it wasn’t to me, I’m not very experienced with FSEvents API and I wouldn’t know if having a single stream watching at “/“ is more efficient than having many streams watching at much smaller set of file paths. I did it for two reasons: firstly it looked (to me) as better design, as all one model object needs is neatly encapsulated within it and secondly, I had a small though about performance and my (perhaps unreasonable) assumption was that path filtering done by Apple folks in file system events daemon would probably perform better than my own filtering in stream’s callback function, being done on a lower lever by much more experienced programmers, having all low lever goodies and tricks on their disposal. And once I didn’t have performance problems with the current implementation, I haven’t look any further. > (may in a separate thread so that you do not hold up the FSEvents handler for > too long - not sure if that's necessary, though). Yeah, my intention for the callback function is just to post a notification with all event paths and flags packed in notification’s userInfo and each observer will use its observing method to immediately kick a separate thread for paths filtering and processing and immediately exit the method. That should keep blocking the event thread on a barely minimum. Of course, if anyone has different ideas, I’d like to hear. > I think doing that is faster than letting the FSEvents system sort them out > for you, and then repeatedly calling your app regardless. Like I’ve said above, my take on that was that file system events daemon would probably do it better than I would have. > So, now that you're figured out that you need to watch "/" anyway, just make > sure you use only one stream to improve overall system performance. > > I see, you've come to the same conclusion in the end, for different reasons > (mine is for performances, yours for avoiding redundancy) :) Well redundancy, but I’m glad if that improves performance as well. Like I’ve said, it’s clear that having more streams watching the same path “/“ is ridiculous and would definitely reduce performance. I just wanted advice if there’s another way to achieve what I need, without being flooded with file events I’m not interested about. > Also, if you need to track changes to the paths of your files, you could > instead use NSURLs made based on file IDs instead of paths, by calling [NSURL > fileReferenceURL]. You could then also store the path alongside, and every > time you learn of possible changes, you resolve the path again to see if it > has moved, if that's what you need to know. What you suggest should cover the situation of any path component along the full file path being changed, right? I don’t know if in such case resolving url’s path is more efficient than comparing strings and asking if an event path(s) is a prefix of a dirname(watchedpath). -- Dragan _______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
