Skip to content

libtracker-miner: Dispatch monitor events on a private thread

Carlos Garnacho requested to merge wip/carlosg/monitor-thread into master 
Each GFileMonitor creates a GSource on the thread default main
context (the main one in our case), this ends up slowing everything
down by the sheer amount of GSources to iterate each time on the
GMainContext, whenever one of those needs dispatching.

As GFileMonitor is friendly to the thread-default main context,
take all file monitoring to a private thread, and make all those
GFileMonitors add their GSources to a separate main context.

Processing of monitor events will still trigger iterations over
large lists of sources, but the main context will not be blocked
by it, thus operations like extracting information from files and
directories will be faster as a result.

Numbers! This brings down first time indexing of 5826 files, 10377
folders from ~40s to 18-20s, and second time indexing from ~30s to
8-9s. Still can't beat enable-monitors=FALSE (15s and 2-3s
respectively), but it is much closer.

Despite monitoring being performed in another thread, we still
need to make the monitor manipulation functions "synchronous" so
that we are sure in our own code that monitor events will be
received after e.g. tracker_monitor_add(). This is necessary for
tests to stay non-racy.

Merge request reports