Module memory 

An in-memory backend and target (DI-D-50 P13, DI-D-52): a deterministic backend, holding each target’s bytes in memory, for testing the core and driving it without a device.

It faults on nothing of its own accord; DI-11.1 adds the fault script. A submission is executed when it is submitted, in push order, and its completion is ready at once. A commit makes the target’s current bytes its durable bytes, so a test can read what a commit warranted.

Refusals. A push is refused with RefusalCause::SubmitNeeded when the submission queue is full, and with RefusalCause::DrainNeeded when as many submissions are queued or completed and not yet popped as the completion queue holds – so a completion always has room – and with RefusalCause::SubmitAndDrainNeeded when both hold.

Structs

MemoryBackend

The in-memory backend. Its buffers are Vec<u8>: a write’s length is its buffer’s, and a read’s the most it transfers.

MemoryNotification

The in-memory backend’s notification: a count of its raisings, which a thread can wait to see pass a value it has seen. Clones share one count, and each keeps its own record of how many raisings its own waits have seen, which starts at none – so a raising before a notification’s first wait is seen by it, as the Windows ring’s setup signal makes one that was raised before the wait began seen.

MemoryTarget

A target whose bytes are held in memory: what was written, and what the last successful commit warranted. It states what it is built with: no flush domains, WarrantyClass::Complete, Geometry::UNALIGNED and Capabilities::NONE unless set.

Constants

MEMORY

The source every fault the in-memory backend reports names.