multithreading - Scala actores vs hilos y bloqueando IO
concurrency (2)
Esto no es un problema de corrección porque la biblioteca del actor generará más subprocesos según sea necesario (¿es correcto?)
Por lo que yo entiendo, eso no es correcto. El actor está bloqueado y el envío de otro mensaje hace que ese mensaje permanezca en el buzón de correo de los actores hasta que ese actor pueda receive o react ante el mensaje.
En Programación en Scala (1), establece explícitamente que los actores no deben bloquear. Si un actor necesita hacer algo durante mucho tiempo, debe pasar el trabajo a un segundo actor, para que el actor principal pueda liberarse y leer más mensajes de su buzón. Una vez que el trabajador ha completado el trabajo, puede señalar ese hecho al actor principal, que puede terminar de hacer lo que tenga que hacer.
Ya que los trabajadores también tienen buzones de correo, usted terminará con varios trabajadores trabajando arduamente en su trabajo. Si no tienes suficiente CPU para manejar eso, sus colas serán cada vez más grandes. Eventualmente puedes escalar usando actores remotos. Akka podría ser más útil en tales casos.
(1) Capítulo 32.5 de Programación en Scala (Odersky, Segunda edición, 2010)
EDIT: encontré esto:
El método del planificador del rasgo Actor se puede anular para devolver un ResizableThreadPoolScheduler, que cambia el tamaño de su grupo de subprocesos para evitar la inanición causada por actores que invocan métodos de bloqueo arbitrarios.
Lo encontré en: http://www.scala-lang.org/api/current/scala/actors/Actor.html
Por lo tanto, eso significa que, dependiendo de la implementación del programador que establezca, tal vez se incremente el grupo utilizado para ejecutar los actores. Me equivoqué cuando dije que estabas equivocado :-) El resto de la respuesta sigue siendo cierto.
Según tengo entendido, los actores son básicamente subprocesos ligeros implementados en la parte superior de los subprocesos, ejecutando muchos actores en un pequeño grupo de subprocesos compartidos.
Dado que ese es el caso, el uso de operaciones de bloqueo en un actor bloquea el hilo subyacente. Este no es un problema de corrección porque la biblioteca de actores generará más hilos según sea necesario (¿es cierto?) Pero luego terminas con muchos y muchos hilos, negando el beneficio de usar actores en primer lugar.
Teniendo en cuenta esto, ¿cómo funcionan los actores cuando necesita realizar dichas operaciones de IO? ¿Hay operaciones que "bloquean al actor", suspendiendo al actor mientras permite que el hilo pase a otras operaciones (como las operaciones de bloqueo suspenden el hilo mientras permiten que la CPU continúe con otras operaciones), o todo está escrito en CPS, con cadena actores? ¿O simplemente los actores no son adecuados para este tipo de operación de larga duración?
Antecedentes: tengo experiencia escribiendo temas de múltiples subprocesos de forma clásica, y entiendo bastante bien cómo funcionan los ciclos de eventos / CPS, pero no tengo absolutamente ninguna experiencia en el trabajo con actores, y solo quiero entender, en un alto nivel, cómo encajan, antes de sumergirme en el código.
Lo que funciona en Erlang es que todas las operaciones de bloqueo deben realizarse mediante el envío de un mensaje, ya que cuando su actor está bloqueado esperando un mensaje, está cediendo el hilo a otro actor.
Por lo tanto, si desea realizar una operación de bloqueo como leer un archivo, debe hacer un actor FileReader que use una API que no te aburre para leer y escribir desde un archivo. Y haga que su otro actor use este actor (envíelo y reciba un mensaje) como una API para leer y escribir en el archivo.