C'est ce que fais le bout de code que j'ai décris plus haut. Les actions 1, 2 et 3 sont asynchrones (pas forcément parallèle) et tu place ton action G dans le subscribe. Si je reprends ta liste :
ça gère que C—E et D—F sont en parallèle => c'est bien ce que je reproche c'est du parallélisme plus que de l'asynchrone. Le fait que ce soit parallèle ou pas est un détail pas un besoin fonctionnel.
ça gère que si l’une des deux branches se plante, il faut interrompre l’autre => ouf ça veut dire quoi ? Je veux dire, il va préempter ton code et tout interrompre ? C'est particulièrement dangereux. Je vois pas bien à quoi ça sert et comment garantir qu'on retombe correctement sur nos pieds avec ça.
les exceptions se remontent toujours au thread principal => c'est un besoin bizarre encore une fois, j'y reviens juste après
ça gère automatiquement le point de rendez-vous avant G => c'est l'équivalent sur subscribe
J'ai vraiment l'impression qu'il s'agit d'un pattern qui sert à ajouter un peu d'asynchrone dans un programme synchrone. Je ne connais pas les autres framework, mais quand tu fais du twist, tu es massivement asynchrone. Remonter dans le contexte principal à chaque fois que quelque chose se passe mal est intenable. Il faut réduire le scope de tes actions et chercher à porter les informations dans des messages plus que dans un état. La gestion d'un état dans un monde asynchrone est sincèrement dangereux parce qu'il est difficile de s'assurer qu'il reste cohérent quelque soit l'ordre dans le quel tes actions asynchrones se résolvent.
[^] # Re: Rx
Posté par barmic . En réponse au journal La programmation concurrente en mode Goto. Évalué à 2.
C'est ce que fais le bout de code que j'ai décris plus haut. Les actions 1, 2 et 3 sont asynchrones (pas forcément parallèle) et tu place ton action G dans le subscribe. Si je reprends ta liste :
J'ai vraiment l'impression qu'il s'agit d'un pattern qui sert à ajouter un peu d'asynchrone dans un programme synchrone. Je ne connais pas les autres framework, mais quand tu fais du twist, tu es massivement asynchrone. Remonter dans le contexte principal à chaque fois que quelque chose se passe mal est intenable. Il faut réduire le scope de tes actions et chercher à porter les informations dans des messages plus que dans un état. La gestion d'un état dans un monde asynchrone est sincèrement dangereux parce qu'il est difficile de s'assurer qu'il reste cohérent quelque soit l'ordre dans le quel tes actions asynchrones se résolvent.