Pregunta ¿En qué se diferencia la implementación de actores múltiples en Scala?


Con el lanzamiento de Scala 2.9.0, también se anunció el Stack Typesafe, que combina el lenguaje Scala con el framework Akka. Ahora, aunque Scala tiene actores en su biblioteca estándar, Akka usa su propia implementación. Y, si buscamos otras implementaciones, también descubriremos que Lift y Scalaz también tienen implementaciones.

Entonces, ¿cuál es la diferencia entre estas implementaciones?


76
2018-05-13 19:47


origen


Respuestas:


Esta respuesta no es realmente mía. Fue producido por Viktor Klang (de la fama de Akka) con la ayuda de David Pollak (de la fama de Lift), Jason Zaugg (de la fama de Scalaz), Philipp Haller (de la fama de Scala Actors).

Todo lo que estoy haciendo aquí es formatearlo (lo cual sería más fácil si Stack Overflow soporta tablas).

Hay algunos lugares que llenaré más tarde cuando tenga más tiempo.

Filosofía de diseño

  • Actores de Scalaz

    Complejidad mínima. Máxima generalidad, modularidad y extensibilidad.

  • Actores de levantamiento

    Mínima complejidad, recolección de basura por JVM en lugar de preocuparse por un ciclo de vida explícito, comportamiento de manejo de errores consistente con otros programas de Scala y Java, espacio de memoria liviano / pequeño, buzón de correo, estáticamente similar a Scala Actors y actores de Erlang, alto rendimiento.

  • Actores de Scala

    Proporcione el modelo completo de Erlang actor en Scala, peso ligero / memoria pequeña.

  • Actores Akka

    Simple y transparentemente distribuible, de alto rendimiento, ligero y altamente adaptable.

Versiones

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Ver. Estable actual 5 2.1 2.9.0 0.10
Mínimo Scala ver. 2.8 2.7.7 2.8
Verificación mínima de Java 1.5 1.5 1.6

Soporte de modelo de actor

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Engendrar nuevos actores sí sí sí sí
dentro del actor
Enviar mensajes a Sí Sí Sí Sí
actor conocido
Comportamiento de cambio Los actores son Sí Sí: anidados Sí:
para el próximo mensaje inmutable reaccionar / recibir convertirse / no recibir
Supervisión No proporcionado No Actor: Sí, Sí
(link / trapExit) Reactor: No

Nivel de aislamiento del estado

Si el usuario define los métodos públicos en sus Actores, ¿son invocables desde ¿el exterior?

  • Actores Scalaz: n / a. El actor es un rasgo sellado.
  • Actores de levantamiento: sí
  • Actores de Scala: Sí
  • Actores Akka: No, la instancia del actor está protegida detrás de un ActorRef.

Tipo de actor

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

Actor gestión del ciclo de vida

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Inicio manual No No Sí Sí
Parada manual No No No Sí
Restart-on-failure n / a Sí Sí Configurable por instancia de actor
Reiniciar semántica n / a Reanudar actor Restaurar actor a estado estable reasignándolo y
                                                    comportamiento tirar la vieja instancia
Reinicie la configurabilidad n / a n / a X veces, X veces dentro de Y time
Se proporcionan ganchos de ciclo de vida Sin ciclo de vida actúan preStart, postStop, preRestart, postRestart

Modos de envío de mensajes

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Fuego-olvídate! mensaje actor! msg actor! msg actorRef! msg
                    un mensaje)
Enviar-recibir-responder (ver 1) actor!? msg actor!? msg actorRef !! msg
                                    actor !! msg
Enviar-recibir-futuro (ver 2) actor !! msg actorRef !!! msg
Enviar-resultado-de-promesa (mensaje). future.onComplete (f => a! f.result)
futuro para (actor)
Componente actor con actor comap f No No No
función (ver 3)

(1) Cualquier función f se convierte en tal actor:

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

(2) Cualquier función f se convierte en tal actor:

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

(3) Functor contravariante: actor comap f. También la composición de Kleisli en Promise.

Modos de respuesta de mensaje

TBD

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
reply-to-sender-in-message
responder a mensaje

Procesamiento de mensajes

Admite recepciones anidadas?

  • Actores Scalaz: -
  • Agentes de levantamiento: Sí (con un poco de codificación manual).
  • Actores Scala: Sí, tanto la recepción basada en el hilo como la reacción basada en el evento.
  • Actores Akka: No, la recepción de anidamiento puede provocar fugas de memoria y un rendimiento degradado a lo largo del tiempo.

Mecanismo de ejecución de mensajes

TBD

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Nombre del mecanismo de ejecución
Mecanismo de ejecución es
configurable
Mecanismo de ejecución puede ser
especificado por actor
Ciclo de vida del mecanismo de ejecución
debe ser administrado explícitamente
Ejecución de hilo por actor
mecanismo
Mecanismo de ejecución impulsado por eventos
Tipo de buzón
Admite buzones transitorios
Admite buzones persistentes

Distribución / Actores remotos

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Transparente a distancia n / a No Sí Sí
actores
Protocolo de transporte n / a n / a Protocolo remoto Java Akka
                                                    serialización (Protobuf en la parte superior de TCP)
                                                    encima de TCP
Agrupación dinámica n / a n / a n / a En oferta comercial

Howtos

TBD

                    Scalaz Actors Lift Actors Scala Actores Akka Actors
Definir un actor
Crear una instancia de actor
Comience una instancia de actor
Detener una instancia de actor

95
2018-05-13 20:53



  • scala.actors fue el primer intento serio de implementar la concurrencia al estilo de Erlang en Scala que ha inspirado a otros diseñadores de bibliotecas a realizar implementaciones mejores (en algunos casos) y más efectivas. El mayor problema (al menos para mí) es que, a diferencia de los procesos de Erlang, se complementa con OTP (eso permite construir sistemas tolerantes a fallas), scala.actors solo ofrezca una buena base, un conjunto de primitivas estables que se deben usar para construir marcos de más alto nivel; al final del día, tendrá que escribir sus propios supervisores, catálogos de actores, máquinas de estados finitos, etc. encima de los actores.

  • Y aquí Akka viene al rescate, ofreciendo una pila con todas las funciones para el desarrollo basado en actores: actores más idiomáticos, conjunto de abstracciones de alto nivel para la coordinación (equilibradores de carga, grupos de actores, etc.) y la construcción de sistemas tolerantes a fallas (supervisores, portado desde OTP, etc.), planificadores fácilmente configurables (despachadores), etc. Lo siento, si sueno grosero, pero creo que no habrá fusión en 2.9.0+ - Prefiero esperar Akka actores para reemplazar gradualmente la implementación de stdlib.

  • Scalaz. Normalmente tengo esta biblioteca en la lista de dependencias de todos mis proyectos, y cuando, por alguna razón, no puedo usar Akka, sin bloqueo Scalaz Promises (con toda la bondad, como sequence) combinado con los actores estándar están salvando el día. Nunca usé Scalaz actores como reemplazo de scala.actors o Akka, sin embargo.


23
2018-05-13 21:13



Actores: Scala 2.10 vs Akka 2.3 vs Lift 2.6 contra Scalaz 7.1

Código de prueba & resultados para latencia promedio y rendimiento en JVM 1.8.0_x.


2
2018-04-02 10:24