Re: FSEvents API and sandboxing
Re: FSEvents API and sandboxing
- Subject: Re: FSEvents API and sandboxing
- From: Dragan Milić <email@hidden>
- Date: Wed, 15 May 2019 14:18:31 +0200
> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden