Re: Rx

Je crois effectivement que tu ne saisis pas bien le concept.

Imagine un programme qui réalise les actions suivantes : A—B—C—E—G, et à l’étape B, il y a déclenchement d’une action parallèle dont le cheminement est D—F. Supposons maintenant que l’on s’attende à ce que cette branche parallèle soit terminée au moment où G se déroule : normalement, tu devrais programmer dans le thread principal une attente (passive) de la fin du thread secondaire. Si je comprends bien, avec Trio, tu as quelque chose comme ça :

A
B
avec nursery(...) as n:
 n.lancer(C—E)
 n.lancer(D—F)
G

et automatiquement :

• ça gère que C—E et D—F sont en parallèle
• ça gère que si l’une des deux branches se plante, il faut interrompre l’autre
• les exceptions se remontent toujours au thread principal
• ça gère automatiquement le point de rendez-vous avant G

C’est déjà pas mal.

Maintenant, si tu n’as pas à proprement parler de notion de « tâches parallèles » mais juste le souhait d’avoir une tâche en arrière-plan, c’est pareil. Ainsi, si tu as le traitement A—B—C, où à B tu déclenches en arrière-plan la tâche de fond D, et que tu veux juste que tout ça fonctionne jusqu’à la fin du programme, tu obtiens ça :

A
B
avec nursery(...) as n:
 n.lancer(C)
 n.lancer(D)

et tu bénéficie toujours de tous les avantages sus-mentionnés (sauf le point de rendez-vous bien sûr).

Là où Trio sera contre-productif, c’est si tu fork dans le but de laisser une tâche de fond qui continue au-delà de la fin du programme.