1. Flyology
  2. Runtime

Core component

Flyology Runtime

An experimental GNAT runtime extension for ordinary Ada tasking. Native tasks keep their OS threads, while explicitly designated lightweight tasks run cooperatively on shared event loops.

Start with the runtime guide Read the runtime architecture
lightweight_task.adb
task Connection is
   pragma Task_Info
     (Flyology.Lightweight_Task);
end Connection;

Flyology.IO.Sockets.Receive
  (Socket, Buffer, Last, Timeout => 1.0);
Native by defaultWith the native project default, undesignated Ada tasks retain the stock OS-thread path.
Ordinary Ada semanticsBoth lanes retain task identity, rendezvous, protected objects, and exceptions.
Lazy event machineryNo event loop starts until the first lightweight task activates.

Programming model

Two lanes share one tasking language.

The designation changes where a task executes. It does not introduce an async dialect or replace Ada task semantics.

01 / LIGHTWEIGHT

Shared event-loop thread

task Atask Btask C
schedulerpoller
02 / NATIVE

Dedicated OS thread

Ada tasktask runtimeOS thread

Runtime architecture

Each mechanism has one responsibility.

The poller reports readiness. The scheduler selects a runnable fiber. The context switch preserves its stack. GNARL continues to define Ada task behavior.

Read the architecture guide
  1. 01

    Event polling

    The runtime uses kqueue on Darwin to wait for readiness and completion. On Linux, it uses epoll for readiness and eventfd for cross-thread wakes.

  2. 02

    Cooperative scheduling

    Per-group priority queues and deadline heaps select ready work. CPU-bound lightweight tasks must reach a cooperative safe point.

  3. 03

    Stackful contexts

    Guarded stacks and a small register swap preserve locals, exception state, task identity, and synchronous control flow.

  4. 04

    Ada task semantics

    Rendezvous, protected objects, activation, masters, abort, and task identity retain their ordinary meanings.

Included building blocks

Synchronous APIs keep operational boundaries explicit.

The runtime crate includes task-aware I/O and bounded systems primitives. Capacity, ownership, recovery, cancellation, and blocking remain explicit.

Runtime guideArchitectureAPI reference
Task-aware I/O
Sockets, files, timers, DNS, TLS, file watching, and subprocess pipes.
Execution control
Shared and dedicated groups, migration, pool sizing, and thread pins.
Bounded coordination
Ownership-transfer buffers, channels, and structured task supervision.
Shared storage
Mappings, descriptor handoff, arenas, rings, maps, vectors, and slab pools.

Runtime boundaries

Constraints are part of the interface.

Flyology Runtime does not claim hard real-time behavior, preemptive lightweight scheduling, production qualification, or universal compiler portability.

Review current constraints
ConcernContract
CompatibilityWith the native project default, undesignated tasks remain native. Event machinery starts lazily.
FairnessScheduling within a group is cooperative, with explicit safe points.
Foreign callsBlocking foreign work belongs on a native task or an explicit native boundary.
Compiler supportRuntime preparation accepts only exact verified compiler patch families.

Build your first lightweight task.

Open the runtime guideExplore the libraries