`ExoJob` is a wrapper class for asynchronous jobs and Thunar depends heavily on it. But it has critical flaws that hinders Thunar from achieving true asynchronous operation. **1. `ExoJob` depends on `GIOScheduler`, which is deprecated as of year 2013** `GIOScheduler` is deprecated as of GLib 2.36. `GTask` replaces this one and provides an easy way to build an asynchronous operation and this also can be used to create synchronous version of an asynchronous operation. Since `ExoJob` depends on `GIOScheduler`, it does not provide a wrapper for methods of `GTask`. **2. Task priority of an `ExoJob` is always `G_PRIORITY_HIGH`** Which means, every `ExoJob`s and its derivatives are always top priority. Its priority is too high that it supercedes everything including timeouts, signal calls, and lo and behold, user interactions. Simply starting few dozens of them would make applications stutter. Setting this priority to somewhat lower would help this problem, but changing priority may cause heisenbugs. It should provide a way to set priority anyways. **3. Identity as "the class that handles asynchronous operations" and "an asynchronous operation itself" are mixed up** `ExoJob` by itself represents an asynchronous operation, but its subclasses in Thunar are enormous classes that manage asynchronous operations. This does not get along with the Glib/GTK way, which is chaining asynchronous operations to build new one. So it should be divided to two parts. The former could be replaced with `GTask` or its sub-class (let me call it `ExoTask`) and the latter could use `ThunarJob` for its pointer. --- To summarize: `ExoJob` might have been a good wrapper for `GIOScheduler`, but it is quite outdated for its job and could be replaced with `GTask`.