Re: FSEvents API and sandboxing
Re: FSEvents API and sandboxing
- Subject: Re: FSEvents API and sandboxing
- From: Thomas Tempelmann <email@hidden>
- Date: Thu, 16 May 2019 20:28:14 +0200
On Thu, May 16, 2019 at 7:43 PM Dominic Giampaolo <email@hidden>
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 (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).
> >
> I don't know how/why you would come to this conclusion.
>
> It is always more efficient to filter things as far up the stream as
> possible. Filtering in fseventsd avoids it sending events that wake up
> your daemon/app for paths it isn't interested in. This is going to be
> better from all perspectives: cpu usage, power consumption, and memory
> usage. Watching "/" gets a *lot* of events which means you daemon or app
> gets woken up very frequently.
>
Okay, maybe my case, where I believe watching "/" is best comes from the
fact that my app doing this is a file browser that usually shows files from
all over the disk, after doing a file search on the disk.
If I show a few 100 files from all over the disk, I it easier to just ask
to watch for "/" than for 100s of different dirs. I assumed that in this
case FSEvents might be overburdened with sorting out all those dirs,
because it's designed to look only for a small amount. Maybe I got this
impression from old docs suggesting something like that, but I'm not sure.
Also, my app is in the foreground for that anyway, so it's not as much an
impact if I do this badly compared to a bg app that does this all the time.
Also, I only request an update a few times per second, i.e. I then get the
entire bunch of changes in one go, and sort them out myself. That should
put less stress on the FSEvents management, because it does not have to
sort it out for me, and it has all the data assembled anyway. I think.
Maybe I have this all wrong. Without much info on how FSEvents internally
works, it's difficult to get this right. I make assumptions on the way I'd
have implemented it.
I see your points, though, and I should have been more aware of the
possibility that Dragan's requirements are different from mine and my
advice therefore not being good.
Thomas
_______________________________________________
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