Tu parles d'Erlang. Mais sauf si quelque chose à changé ces dernières années, Erlang expose un modèle à acteur. C'est à dire une API qui expose le message passing et la gestion d'erreur qui doit en découler. Ce design DOIT être au cœur de ton application.
Bref si tu es satisfait des acteurs d'Erlang, on dit la même chose...
plutôt que des threads et des fonctions ne change pas grand chose à l'affaire.
Dès que tes communications deviennent asynchrone gloups...
Des précisions ?
Lis le deuxième papier, il fait quatre page. "Convenience Over Correctness" le résume bien. Un carré ne sera jamais rond.
sur des systèmes distribués
Si tu parles de système distribué, alors ne pas masquer la sémantique d'un envoi de message hors du processus est vital. Les acteurs sont excellent à ça, jamais vu une implémentation d'objet actif réussir à le faire correctement (ou plus élégamment que des acteurs).
[^] # Re: Retour sur les objets actifs
Posté par ckyl . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 3.
Tu parles d'Erlang. Mais sauf si quelque chose à changé ces dernières années, Erlang expose un modèle à acteur. C'est à dire une API qui expose le message passing et la gestion d'erreur qui doit en découler. Ce design DOIT être au cœur de ton application.
Si tu vas sur la JVM, tu as Akka qui fait la même chose et qui dit la même chose que moi sur les limitations des objets actifs
Bref si tu es satisfait des acteurs d'Erlang, on dit la même chose...
Dès que tes communications deviennent asynchrone gloups...
Lis le deuxième papier, il fait quatre page. "Convenience Over Correctness" le résume bien. Un carré ne sera jamais rond.
Si tu parles de système distribué, alors ne pas masquer la sémantique d'un envoi de message hors du processus est vital. Les acteurs sont excellent à ça, jamais vu une implémentation d'objet actif réussir à le faire correctement (ou plus élégamment que des acteurs).