Concurrence structurée

seed utilise structuré spawn, typé ordinaire task/synchronization bibliothèques et un runtime hébergé M:N. Il n'a pas async/await ou des fonctions colorées.

Apparition

fn compute(value: i64) {
    spawn {
        let answer = value + 1
    }
}

Le compilateur décrit le corps dans un travailleur interne et crée un environnement de capture copy/move concret. Chaque arête quittant la portée lexicale propriétaire attend son groupe de tâches avant le nettoyage, de sorte qu'une tâche ne peut pas accidentellement survivre à l'état stack/region capturé.

Les captures nécessitent send; l'accès simultané partagé nécessite en outre sync. Conserver l'original lors de l'envoi d'une ressource nécessite un clone explicite. L’état global mutable ne peut pas être capturé, directement ou via un assistant. Suffixe ? ne peut pas franchir la limite des tâches pendant que les corps de tâches reviennent void.

Bibliothèque de tâches

compiler/llvm/libs/task est un package générique ordinaire. Il fournit :

Import/source-elide ce package avant d’utiliser ces types. La langue elle-même ne définit pas chan<t>, send, recv, canaux de rendez-vous, spawn détaché ou spawn for syntaxe.

Planificateur

Linux-natif x86-64/AArch64 fournir des planificateurs structurés sans libc. Bloquer le parc d'opérations de la bibliothèque de tâches via le contrat d'exécution au lieu d'épingler un travailleur. Les enregistrements de tâches contiennent un contexte d'allocation actif ; le travail lié à la région se joint avant la sortie de la région.

Windows x86-64 utilise CreateThread avec les jointures de groupes lexicaux et la bibliothèque de tâches channel/join exécution, couverte par l’exécution Wine requise. Le macOS x86-64 et bras64 runtime/link les surfaces utilisent la planification pthread ; Intel natif x86-64 l'exécution reste la Gate 14 élément de fermeture, tandis que arm64 est explicitement à liaison croisée uniquement.

Résultats de tâches saisis

task_result_new<t, e>(), task_result_complete_ok/error, et task_result_wait spécialiser les points finaux linéaires à un coup sur result<t,e>. Le succès et l'échec composent sans async/await; la poignée reste uniquement en mouvement, le blocage est explicite, les captures nécessitent toujours send, et les handles basés sur une région ne peuvent pas échapper à leur région. Ceci est une surface de bibliothèque, donc spawn reste faible et les coûts des tâches restent visibles.