Redoing File Operation Management in Nautilus

This will serve as a sort of introduction to my project, as well as being a progress update.

Hi, I’m Ernestas and this summer I’m working on Nautilus as part of Google Summer of Code. The goal of the project is to have all I/O operations (i.e. file management, the cache, thumbnailing, searching) managed under a single entity with a capped worker thread count.

This talk by my mentor, Carlos, gives a reason why this is needed in a file manager – searching. Dropping down to the root folder and searching for something as innocent as, say, “a” will likely result in your demise, as Nautilus will happily perform an aggressive benchmark on your system instead of searching. Limiting the number of search jobs will help reduce the random reads performed by the disk as well as leaving the system in a usable state.

Another positive outcome is making the code more object-oriented – going from plain function calls and routing events in a very roundabout way to self-contained task classes with signals to provide progress information (e.g. file task progress, search hits, enumerating directory children for cache purposes) and all other nutrients required for a strong file manager. If the result is not having to split the vim window in four just to work in a nautilus-file-operations.c or nautilus-directory-async.c-equivalent file, I will be damn pleased.

The first two weeks haven’t been very eventful, as the exam schedule in my university clashes a bit with GSoC, but in a few days I will be able to return full-speed. Despite that, one of the goals has been reached – implementing a bare-bones task manager, creating a task API skeleton and porting over a file operation. The wip/ernestask/tasks branch contains the code if you’re interested.

The task manager currently allows limiting the running task count at compile time, but Carlos and I have discussed a more dynamic approach to take, once the groundwork is laid. As the task interface is generic, doing things like preventing conflicting operations as they are queued is a bit of a head-scratcher, but that will probably work out with error callbacks and the like. Another thing that is desirable is turning the manager into a scheduler of sorts, which can assign priorities to tasks, in turn letting short-lived, user-facing tasks take precedence (or something else entirely, this is yet to be decided).

Writing the tasks themselves is an experience in itself, requiring deep and wide class hierarchies (not to mention loads of private helper functions) to accomodate all idiosyncrasies of the code, but so far it’s been relatively straightforward. I’ll bet that a rain jacket will not help in the storm that is going to be shuffling around the code for the cache operations. :)

Talk to you again in a couple of weeks,