Skip to main content

PayloadSink

znippy_plugin_git::exploded

Trait PayloadSink 

Source 
pub trait PayloadSink: Sync {
    // Required method
    fn explode(
        &self,
        oid: &[u8],
        kind: GitObjectKind,
        payload: &[u8],
    ) -> Result<()>;

    // Provided methods
    fn wants(&self, _kind: GitObjectKind) -> bool { ... }
    fn flush(&self) -> Result<()> { ... }
}
Expand description

Where every object the resolver produces is handed over.

A sink rather than a return value: crate::resolve::resolve_walked already drops a blob payload the moment nothing else in the pack deltas against it, and returning every payload instead would mean the whole pack inflated in RAM at once. Streaming it out keeps the resolver’s peak footprint exactly what it was before this table existed.

Required Methods§

Source

fn explode(&self, oid: &[u8], kind: GitObjectKind, payload: &[u8]) -> Result<()>

One resolved object: its oid, the type its chain resolves to, and the inflated payload. Called once per pack entry, never for a delta’s intermediate state.

Provided Methods§

Source

fn wants(&self, _kind: GitObjectKind) -> bool

Will this sink read the payload of an object of this kind?

The resolver asks before it produces one, and does not call explode at all when the answer is no. That is not an optimisation the resolver invented: since lane Q the shipped policy is ExplodePolicy::Commits, which drops trees and blobs — 90 % of the objects and essentially all of the bytes — on the sink’s own doorstep. Asking first is what lets the resolver hand its objects over in entry order without buffering those bytes to do it, and the ordered hand-over is what makes the stream the same at one worker and at four.

The default is yes for everything, which is the old behaviour exactly. A sink that answers no is responsible for its own counters — it will not be told about the object at all.

Source

fn flush(&self) -> Result<()>

Write down whatever is buffered. Called by the resolver when the memory watchdog says the box is short (crate::memguard) and at the end of a pack; a sink that buffers nothing has nothing to do.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§