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

Avec la sortie de Scala 2.9.0, la stack Typesafe a également été annoncée, combinant 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. Et si nous recherchons d’autres implémentations, nous constaterons également que Lift et Scalaz ont également des implémentations!

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

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

Tout ce que je fais ici est le formatage (ce qui serait plus facile si les tables sockets en charge par Stack Overflow).

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

Philosophie du design

  • Acteurs Scalaz

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

  • Acteurs de levage

    Complexité minimale, récupération de la mémoire par JVM plutôt que de s’inquiéter d’un cycle de vie explicite, comportement de gestion des erreurs cohérent avec les autres programmes Scala et Java, encombrement mémoire faible, boîte aux lettres, statiquement similaire aux acteurs Scala et Acteurs Scala.

  • Scala Acteurs

    Fournir l’intégralité du modèle d’acteur Erlang dans Scala, encombrement léger / petit.

  • Akka Acteurs

    Dissortingbution simple et transparente, haute performance, légère et hautement adaptable.

Versioning

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Actuel stable ver.  5 2,1 2,9,0 0,10
 Minimum Scala ver.  2.8 2.7.7 2.8
 Java minimum  1,5 1,5 1,6

Prise en charge du modèle d’acteur

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Créer de nouveaux acteurs Oui Oui Oui Oui
 à l'intérieur de l'acteur
 Envoyer des messages à Oui Oui Oui Oui
 acteur connu 
 Changer le comportement Les acteurs sont Oui Oui: nested Oui:
 pour le prochain message immuable, réagir / recevoir devenir / devenir incompréhensible
 Supervision Non fourni Non Acteur: Oui, Oui
 (link / trapExit) Réacteur: Non

Niveau d’isolement de l’état

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

  • Scalaz Acteurs: n / a. L’acteur est un trait scellé.
  • Acteurs de levage: Oui
  • Scala Acteurs: Oui
  • Akka Actors: Non, l’instance d’acteur est protégée par un ActorRef.

Type d’acteur

  • Acteurs Scalaz: Actor[A] extends A => ()
  • Acteurs de levage: LiftActor , SpecializeLiftActor[T]
  • Scala Acteurs: Reactor[T] , Actor extends Reactor[Any]
  • Akka Acteurs: Actor[Any]

Gestion du cycle de vie des acteurs

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Démarrage manuel non non oui oui
 Arrêt manuel Non Non Non Oui
 Redémarrage sur échec so Oui Oui Configurable par instance d'acteur
 Redémarrez la sémantique n / a Réexécutez l'acteur Restaurez l'acteur à l'état stable en le ré-affectant et
                                                     comportement jeter la vieille instance
 Redémarrez la configurabilité n / an / a X fois, X fois dans le temps Y
 Crochets de cycle de vie fournis Pas d'acte de cycle de vie pré-démarrage, post-arrêt, pré-redémarrage, post-redémarrage

Modes d’envoi de message

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Ignorer le feu a!  acteur de message!  msg acteur!  msg actorRef!  msg
                     un message)
 Envoyer-recevoir-répondre (voir 1) acteur!?  msg acteur!?  msg actorRef !!  msg
                                     acteur !!  msg
 Send-receive-future (voir 2) acteur !!  msg actorRef !!!  msg
 Envoyer-résultat-de-promesse (message).  future.onComplete (f => à! f.result)
 avenir à (acteur)
 Composer acteur avec comap acteur f Non Non Non
 fonction (voir 3)

(1) Toute fonction f devient un tel acteur:

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

(2) Toute fonction f devient un tel acteur:

 val a = f.promise val replyFuture = a(message) 

(3) foncteur actor comap f : actor comap f . Aussi composition Kleisli dans Promise .

Modes de réponse aux messages

À déterminer

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 répondre à l'expéditeur du message
 répondre au message

Traitement des messages

Prise en charge nestede reçoit?

  • Scalaz Acteurs: –
  • Acteurs de levage: Oui (avec un peu de codage manuel).
  • Scala Actors: Oui, à la fois la réception par thread et la fonction basée sur les événements.
  • Akka Actors: Non, l’imbrication reçue peut entraîner des memory leaks et une dégradation des performances au fil du temps.

Mécanisme d’exécution de message

À déterminer

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Nom du 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
 Cycle de vie du mécanisme d'exécution
 doit être explicitement géré
 Exécution des threads par acteur
 mécanisme
 Mécanisme d'exécution piloté par les événements
 Type de boîte aux lettres
 Prend en charge les boîtes aux lettres transitoires
 Prend en charge les boîtes aux lettres persistantes

Acteurs de dissortingbution / distants

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Télécommande transparente so Non Oui Oui
 acteurs
 Protocole de transport n / a / un protocole distant Java Akka
                                                     sérialisation (Protobuf sur TCP)
                                                     sur TCP
 Cluster dynamic n / a / an Dans l'offre commerciale

Mode d’emploi

À déterminer

                     Scalaz Acteurs Lift Acteurs Scala Acteurs Akka Acteurs
 Définir un acteur
 Créer une instance d'acteur
 Démarrer une instance d'acteur
 Arrêter une instance d'acteur
  • scala.actors a été la première tentative sérieuse de mise en œuvre de la concurrence de style Erlang dans Scala qui a inspiré d’autres concepteurs de bibliothèques à réaliser des implémentations plus performantes (dans certains cas) et plus performantes. Le plus gros problème (au moins pour moi) est que, contrairement aux processus Erlang, complétés par OTP (qui permet de créer des systèmes tolérants aux pannes), scala.actors n’offre qu’une base solide, un ensemble de primitives stables à utiliser pour construire des frameworks de plus haut niveau – en fin de compte, vous devrez écrire vos propres superviseurs, catalogues d’acteurs, machines à états finis, etc. au-dessus des acteurs.

  • Et ici, Akka vient à la rescousse, offrant une stack complète pour le développement basé sur les acteurs: des acteurs plus idiomatiques, un ensemble d’abstractions de haut niveau pour la coordination (équilibreurs de charge, pools d’acteurs, etc.) et la construction de systèmes tolérants aux fautes , portés depuis OTP , etc.), des ordonnanceurs facilement configurables (dispatchers), etc. Désolé, si je parais désagréable, mais je pense qu’il n’y aura pas de fusion dans la version 2.9.0+ – je préférerais que les acteurs d’ Akka remplacent progressivement l’implémentation de stdlib.

  • Scalaz . Normalement, j’ai cette bibliothèque dans la liste des dépendances de tous mes projets, et quand, pour une raison quelconque, je ne peux pas utiliser Akka , les promesses Scalaz non bloquantes (avec toute la bonté, comme la sequence ) combinées avec les acteurs standard sont sauvegardées le jour. Je n’ai jamais utilisé d’acteurs Scalaz en remplacement des scala.actors ou d’ Akka , cependant.

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

Tester le code et les résultats pour obtenir une latence et un débit moyens sur JVM 1.8.0_x.