I have a thread watching for file system events on Mac OS X. If I copy 100 files into a folder that is being watched, I obviously get multiple file system events, and therefore multiple callback calls. I'm wondering if these callback calls are processed one after another? Or does each event invoke an OS thread, which in turn calls the callback function, in which case we would have multiple threads each executing the same callback function?
It depends which mechanism you're using to watch file system events.
Every access to a file generates a notification inside a kernel.
If you use the public FSEvents API, too frequent updates are coalesced to a single notification. This case, the receiving end is managed by a run loop, i.e. the callback is not called in the new background thread, or the context of the OS thread. It's run in the event loop you specified, usually the main thread which runs the main event-processing loop.
If you directly tap into /dev/fsevents
(see e.g. the OS X book), you get all the events in the calling thread one by one, with possibly multiple events returned by one call.
Similarly, if you instead use BSD-derived kqueue
, you would get multiple events from the call of kqueue
if the events are frequent.
In any case the OS don't run your callback in a new/OS thread, nor magically duplicate your thread watching the file system activity, so that they can process the events simultaneously.