67 Introduction

This part serves as a design specification for a new version of the CEDA LSS. It will attempt to incorporate the proposals in Part VII. In particular, the aim is to make the LSS fully asynchronous and support multi-version concurrency control (MVCC).

Version 2 is not required to be compatible with Version 1. Its APIs, in-memory structures and persistent file format may change where that produces a better design.

The aim is to implement the LSS as a pure event-driven state machine, without using coroutines. An event causes the LSS to update its state and may synchronously produce further work or notifications. Operations that require I/O return to the caller and continue later when the RAS reports completion.

For example, the RAS may call back into the LSS with OnReadComplete(). The LSS can use that event to make a newly loaded segment available in the segment cache. Making the segment available may in turn allow pending reads of serial elements to continue: the LSS copies data into their destination buffers with memcpy() and, when those reads are complete, notifies applications built on top of the LSS. In this way, a native I/O completion can drive a sequence of state transitions and application notifications without suspending a coroutine or blocking a thread.

Although the intention is for LSS Version 2 to support asynchronous I/O, it may be better for the initial implementation to use synchronous I/O because that is simpler. Moving to asynchronous I/O can reasonably be treated as a later task. It is better to keep the initial problem simple enough to reason about and obtain good solutions than to introduce so much complexity that progress is slow and mistakes are made.

Although Version 2 is not being implemented in Rust, it is useful to confirm that the design has a straightforward mapping to a borrow checker. Borrow checking often forces ownership and lifetime relationships to be expressed clearly and therefore encourages good design.

The aim is for the Version 2 specification to be sufficiently precise and complete for AI code generators to implement it. If the design, interfaces, ownership rules and persistent formats are specified clearly enough, the resulting implementation will probably be both efficient and correct.

The specification must define the binary representation of the LSS file unambiguously.

Performance principles

The current LSS is already fast, and profiling has shown that a significant proportion of its time can be spent in memcpy(). Version 2 changes how the LSS waits for work, but must not make the existing data path less efficient. In particular, asynchrony must not introduce additional payload copies merely to simplify ownership or completion handling.

RAS reads target their final segment-cache buffers directly. The RAS fills the buffer supplied in a RASReadRequest, and completion transfers that buffer back to the LSS without an intermediate RAS or event buffer. Similarly, an LFU is constructed in the buffer from which the RAS writes it. The WSN completion contract keeps that original buffer alive until the native write no longer needs it, so asynchronous writing does not require a staging copy.

Events carry lightweight operation identities or references to existing state, not copies of payload data. A read-completion event can refer to its RASReadRequest, a segment-cache event can refer to its segment, and write progress is represented by two counters. Internal event dispatch must not move segment or serial-element contents between buffers.

When an application asks the LSS to fill an application-owned buffer, copying data from cached segments into that buffer remains necessary. The implementation should preserve large contiguous memcpy() operations where the packet layout permits them. Existing interfaces that safely provide a direct read-only view of resident data should remain zero-copy and must not be routed through a copied result merely for uniformity with asynchronous operations.

Native I/O may usefully overlap CPU work. For example, the device can load one segment while the LSS copies data from another resident segment. This does not imply that several CPU threads should perform payload copies concurrently. Parallel copies can compete for memory bandwidth and disrupt cache locality, so that form of concurrency should be introduced only when profiling demonstrates a benefit.

For equivalent operations, Version 2 should perform no more payload copies than the current LSS solely because it is asynchronous. Performance tests should compare the two versions and record at least the number of payload copies, bytes copied per application byte, average copy size, heap allocations, event dispatches, cross-thread hand-offs and overall throughput. RAS staging copies and payload copies inside events should both be zero.

The specification does not mandate a particular event queue, object pool, I/O queue depth, batching threshold or thread on which copying occurs. Those are implementation choices to be guided by measurement. The architectural requirement is that asynchronous coordination remains lightweight and does not compromise the efficient buffer usage of the existing LSS.