- /* slab train
- *
- * All in-memory data is contained in a linked list called the "slab
- * train". Various components are operating simultaneously at different
- * points in this train. Data from the upstream XferElement is appended to
- * the head of the train, and the device thread follows along behind,
- * writing data to the device. When caching parts in memory, the slab
- * train just grows to eventually contain the whole part. When using an
- * on-disk cache, the disk cache thread writes the tail of the train to
- * disk, freeing slabs to be re-used at the head of the train. Some
- * careful coordination of these components allows them to operate as
- * independently as possible within the limits of the user's configuration.
- *
- * Slabs are rarely, if ever, freed: the oldest_slab reference generally
- * ensures that all slabs have refcount > 0, and this pointer is only
- * advanced when re-using slabs that have been flushed to the disk cache or
- * when freeing slabs after completion of the transfer. */
-
- /* pointers into the slab train are all protected by this mutex. Note that
- * the slabs themselves can be manipulated without this lock; it's only
- * when changing the pointers that the mutex must be held. Furthermore, a
- * foo_slab variable which is not NULL will not be changed except by its
- * controlling thread (disk_cacher_slab is controlled by disk_cache_thread,
- * and device_slab is controlled by device_thread). This means that a
- * controlling thread can drop the slab_mutex once it has ensured its slab
- * is non-NULL.
- *
- * Slab_cond is notified when a new slab is made available from the reader.
- * Slab_free_cond is notified when a slab becomes available for
- * reallocation.
- *
- * Any thread waiting on either condition variable should also check
- * elt->cancelled, and act appropriately if awakened in a cancelled state.
- */
- GMutex *slab_mutex; GCond *slab_cond; GCond *slab_free_cond;