ReactiveUI.Primitives.Concurrency namespace¶

Part of the ReactiveUI.Primitives package.

Type	Kind	Summary
CurrentThreadSequencer	class	A sequencer that schedules work on the current thread using a trampoline queue.
HandlerSequencer	class	Android sequencer that coalesces scheduled work onto the thread backing a [Handler](# (typically the main/UI looper). Immediate work is batched through a single cached `IRunnable` drain, so the per-post path allocates nothing; delayed work uses the native `PostDelayed`.
ISequencer	interface	Represents an object that schedules units of work.
ImmediateSequencer	class	A sequencer that executes work immediately on the calling thread.
NSRunloopSequencer	class	Apple sequencer that coalesces scheduled work onto the main `DispatchQueue` (the UI thread on iOS, tvOS, Mac Catalyst, and macOS). Immediate work is batched through a single cached `DispatchBlock` drain, so the per-post path allocates nothing; delayed work uses `DispatchAfter`.
ScheduledItem	class	Creates materialized [ScheduledItem](# work items from a sequencer, state, and action.
Sequencer	class	Provides built-in sequencers for scheduling work over time.
SequencerExtensions	class	Scheduling extension operators for an [ISequencer](#
SynchronizationContextSequencer	class	Sequencer that posts work through a SynchronizationContext.
TaskPoolSequencer	class	A sequencer that schedules work on the task pool.
ThreadPoolSequencer	class	A sequencer that schedules work on the thread pool.
VirtualClock	class	Deterministic virtual scheduler backed by DateTimeOffset and TimeSpan.
VirtualTimeSequencer	class	Virtual time scheduler that runs scheduled work against a controllable clock. Per-clock arithmetic is supplied as delegates at construction, so a single sealed type serves every `TAbsolute`/ `TRelative` pairing without an inheritance hierarchy.
VirtualTimeSequencerExtensions	class	Provides a set of extension methods for virtual time scheduling.
WasmSequencer	class	Task-pool replacement for single-threaded event-loop runtimes such as browser WebAssembly: it never starts threads and never blocks. Immediate work is batched one drain per event-loop turn through a zero-due timer (a `setTimeout(0)` macrotask on WebAssembly, so the browser can render between batches); delayed work uses the shared timer, which the WebAssembly runtime backs with the JS event loop.