Comment la mise en œuvre des acteurs multiples en Scala est-elle différente?

Question

Avec la sortie de Scala 2.9.0, la pile Typesafe a également été annoncée, qui combine le langage Scala avec le framework Akka. Maintenant, bien que Scala ait des acteurs dans sa bibliothèque standard, Akka utilise sa propre implémentation. De plus, si nous cherchons d'autres implémentations, nous trouverons également que Lift et Scalaz en ont aussi!

Alors, quelle est la différence entre ces implémentations?

Answer 1

Cette réponse n’est pas vraiment la mienne. Elle a été produite par Viktor Klang (de Akka fame) avec l’aide de David Pollak (de Lift fame), Jason Zaugg (de Scalaz fame), Philipp Haller (de Scala Actors fame).

Tout ce que je fais ici, c’est la formater (ce qui serait plus facile si Stack Overflow supportait les tableaux).

Il y a quelques endroits que je remplirai plus tard quand j’aurai plus de temps.

Philosophie de conception

• Scalaz Actors

  Complexité minimale. Généralité, modularité et extensibilité maximales.

• Lift Actors

  Complexité minimale, collecte de déchets par la JVM plutôt que de se soucier d’un cycle de vie explicite, comportement de gestion des erreurs cohérent avec d’autres programmes Scala & Java, empreinte mémoire légère/petite, boîte aux lettres, statiquement similaire aux acteurs Scala et aux acteurs Erlang, performances élevées.

• Scala Actors

  Fournir le modèle d’acteur Erlang complet en Scala, empreinte mémoire légère/petite.

• Akka Actors

  Simples et distribuables de manière transparente, performances élevées, légers et très adaptables.

Version

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Version stable act. 5               2.1             2.9.0           0.10
Version min. Scala   2.8             2.7.7                           2.8
Version min. Java                     1.5             1.5             1.6

Support du modèle d'acteur

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Créer nouveaux       Oui             Oui             Oui             Oui
acteurs à l’intérieur
d’un acteur
Envoyer des messages Oui             Oui             Oui             Oui
à un acteur connu
Changement de       Les acteurs     Oui             Oui : réagissent  Oui :
comportement pour   sont immuables                  / reçoivent      deviennent/renoncent
le prochain message                                 imbriqués       à devenir
Supervision         Non fourni      Non             Acteur : Oui,    Oui
(lien/trapExit)                                      Réacteur : Non

Niveau d'isolement de l'état

Si l’utilisateur définit des méthodes publiques sur ses acteurs, celles-ci sont-elles appelables de l’extérieur?

• Scalaz Actors : n/a. L’acteur est un trait scellé.
• Lift Actors : Oui
• Scala Actors : Oui
• Akka Actors : Non, l’instance de l’acteur est protégée derrière une ActorRef.

Type d'acteur

• Scalaz Actors : Acteur[A] étend A => ()
• Lift Actors : LiftActor, SpecializeLiftActor[T]
• Scala Actors : Réacteur[T], Acteur étend Réacteur[N’importe]
• Akka Actors : Acteur[N'importe]

Gestion du cycle de vie de l’acteur

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Démarrage manuel    Non             Non             Oui             Oui
Arrêt manuel        Non             Non             Non             Oui
Redémarrage en cas  n/a             Oui             Oui             Configurable par instance d’acteur
d’échec
Sémantique de       n/a             n/a             Refaire acteur   Restaurer l’acteur à un état stable en le
redémarrage                                         comportement     réallouant et en jetant l’ancienne instance
configurabilité                   n/a             X fois, X fois dans Y temps
Crochets de cycle de vie fournis    Aucun cycle de vie   acte            preDébut,
                                     preRetchet, postArrêt, preRedémarrage, postRedémarrage

Mode d'envoi de messages

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Envoyer-et-oublier  a ! message     acteur ! msg    acteur ! msg    acteurRef ! msg
                    a(message)
Envoyer-recevoir-réponse    (voir 1)        acteur !? msg    acteur !? msg    acteurRef !! msg
Envoyer-recevoir-futur       (voir 2)                         acteurRef !!! msg
Envoyer-résultat-de-        promesse(message).                 le futur.onComplet( f => à ! f.result )
futur                       vers(acteur)
Combiner l'acteur avec la  acteur comap f   Non             Non             Non
fonction                    (voir 3)

(1) Toute fonction f devient un tel acteur :

val a: Msg => Promise[Rep] = f.promise
val réponse: Rep = a(msg).get

(2) Toute fonction f devient un tel acteur :

val a = f.promise
val futur de réponse = a(message)

(3) Foncteur contravariant : acteur comap f. Aussi composition Kleisli dans Promise.

Mode de réponse aux messages

TBD

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
répondre à l'expéditeur dans le message
répondre au message

Traitement des messages

Prise en charge des réceptions imbriquées?

• Scalaz Actors : --
• Lift Actors : Oui (avec un peu de codage manuel).
• Scala Actors : Oui, réception basée sur les threads et réaction basée sur les événements.
• Akka Actors : Non, l’imbrication des réceptions peut entraîner des fuites de mémoire et des performances dégradées avec le temps.

Mécanisme d'exécution des messages

TBD

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Nom pour le Mécanisme d'Exécution
Le mécanisme d'exécution est
configurable
Le mécanisme d'exécution peut être
spécifié sur une base par acteur
Le cycle de vie du mécanisme d'exécution
doit être géré explicitement
Mécanisme d’exécution par fil
Mécanisme d’exécution basé sur des événements
Type de boîte aux lettres
Prise en charge des boîtes aux lettres temporaires
Prise en charge des boîtes aux lettres persistantes

Acteurs distants/rémotes

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Acteurs distants    transparents    Non             Oui             Oui
protocole de transport        n/a             n/a             Java            Protocole distant Akka
                                                    serialization   (Protobuf sur TCP)
                                                    sur TCP
Cluster dynamique    n/a             n/a             n/a             Dans une offre commerciale

Guides pratiques

TBD

                    Scalaz Actors   Lift Actors     Scala Actors    Akka Actors
Définir un acteur
Créer une instance d’acteur
Démarrer une instance d’acteur
Arrêter une instance d’acteur

Answer 2

• scala.actors était la première tentative sérieuse de mettre en œuvre la concurrence de style Erlang en Scala qui a inspiré d'autres concepteurs de bibliothèques pour créer des implémentations meilleures (dans certains cas) et plus performantes. Le plus gros problème (du moins pour moi) est qu'à la différence des processus Erlang, complétés par OTP (qui permet de construire des systèmes tolérants aux pannes), scala.actors n'offre qu'une bonne base, un ensemble de primitives stables qui doivent être utilisées pour construire des frameworks plus haut niveau - à la fin de la journée, vous devrez écrire vos propres superviseurs, répertoires d'acteurs, machines à états finis, etc. au-dessus des acteurs.

• Et c'est là qu' Akka entre en jeu, offrant une pile complète pour le développement basé sur les acteurs : des acteurs plus idiomatiques, un ensemble d'abstractions de haut niveau pour la coordination (répartiteurs de charge, pools d'acteurs, etc.) et la construction de systèmes tolérants aux pannes (superviseurs, venant d' OTP, etc.), des ordonnanceurs facilement configurables (répartiteurs), et ainsi de suite. Désolé si je semble impoli, mais je pense qu'il n'y aura pas de fusion dans 2.9.0+ - je m'attends plutôt à ce que les acteurs d' Akka remplacent progressivement l'implémentation de la bibliothèque standard.

• Scalaz. Normalement, j'ai cette bibliothèque dans la liste des dépendances de tous mes projets et lorsque, pour une raison quelconque, je ne peux pas utiliser Akka, les Scalaz Promises non bloquantes (avec tous les avantages, comme séquence) combinées avec les acteurs standard sauvent la mise. Je n'ai jamais utilisé les acteurs de Scalaz comme remplacement pour les scala.actors ou Akka, cependant.

Answer 3

Acteurs : Scala 2.10 vs Akka 2.3 vs Lift 2.6 vs Scalaz 7.1

Code de test & résultats pour la latence moyenne et le débit sur JVM 1.8.0_x.