wsdb_scheduler.hpp File Reference

Server-side per-fork ordering for the concurrent wsdb. More...

#include "barretenberg/common/thread_pool.hpp"
#include "ipc_runtime/ipc_server.hpp"
#include <atomic>
#include <cstdint>
#include <deque>
#include <functional>
#include <memory>
#include <mutex>
#include <unordered_map>
#include <utility>

Go to the source code of this file.

Classes
class	bb::wsdb::WsdbScheduler
struct	bb::wsdb::WsdbScheduler::Op
struct	bb::wsdb::WsdbScheduler::Lane

Namespaces
namespace	bb
	Entry point for Barretenberg command-line interface.
namespace	bb::wsdb

Detailed Description

Server-side per-fork ordering for the concurrent wsdb.

Owns the ordering that used to live in the TypeScript client's per-fork WorldStateOpsQueue, moved server-side so the database — not each client — guarantees its own consistency. Handlers classify themselves (a read calls submit_read, a write calls submit_write) and pass the fork they touch, so this scheduler needs no knowledge of the wire format. Per fork:

• committed reads run concurrently, never ordered (independent snapshots);
• uncommitted reads run concurrently with each other but wait behind an in-flight write on the same fork;
• a write is exclusive on its fork: it waits for in-flight ops on that fork to drain, runs alone, and only then are later ops on that fork released. Different forks never block each other.

This is the read-batch / write-barrier model: a run of reads proceeds in parallel; the next write is a barrier; reads after it wait for it.

Threading: submit_* is called only on the reactor thread (arrival order); work runs on the thread pool; completions re-pump under the lock. The inline fast path runs work directly on the reactor thread when nothing is in flight and no further request is pending — so a synchronous single-in-flight client (e.g. an AVM sim) never queues. Lifetime is via shared_from_this so a completion can safely outlive the reactor loop's return.

Definition in file wsdb_scheduler.hpp.