Après avoir lu sur l'utilisation de réacteur code> dans Acteurs de Scala, je pensais réact code> > est en attente. Il ne semble pas être le cas. import scala.actors.Actor
import scala.actors.Actor._
class SleepyReactor extends Actor {
def act() {
loop {
react {
case x => {
println("reacting to %s on thread %s".format(x, Thread.currentThread.getName))
Thread.sleep(1000)
println("done with " + x)
}
}
}
}
}
val sleepyOne = new SleepyReactor
sleepyOne.start
sleepyOne ! "first" // runs on thread-5
// wait until completion
sleepyOne ! "second" // runs on thread-3
4 Réponses :
La bibliothèque du planificateur utilise un pool de threads pour contrôler l'exécution des acteurs. Je ne connais pas les détails de la logique qu'il utilise, mais pour moi, il semblerait naturel de s'attendre à ce qu'il s'attendrait à:
initialiser avec plus d'un fil dans la piscine, car des applications multithread sont très susceptibles d'utiliser plus d'une THEAD.
Sélectionnez le fil à utiliser avec un acteur en attente de manière à la queue - Les fils sont libérés jusqu'à la fin de la file d'attente et acquérir depuis le début de la file d'attente.
En outre, je suppose que certains threads sont utilisés pour gérer la planification elle-même ainsi que le passage du message.
Il est vrai que pour un acteur purement basé sur événement, son code de réaction fonctionne sur le même thread que le code d'envoi de messages.
Mais à Scala, car il n'est pas souhaitable de bloquer un fil lorsqu'un acteur appelle une opération de blocage à l'intérieur de son code de réagité et d'unifier les acteurs basés sur des événements (pouvant les composer), les deux types d'acteurs utilisent La même piscine de fil, mais les acteurs à base de thread obtiennent leurs propres threads, tandis que les acteurs basés sur des événements partage des threads basés sur une file d'attente de tâches. Pour plus de détails, veuillez vous reporter à acteurs qui unifient des threads et des événements par Philipp Haller et Martin Odersky
Ne supposez pas un fil séparé par acteur. Les machines Scala créent une piscine de fils de travailleurs et ne pousse que ce pool si la taille des acteurs «bloqués» est supérieur à la taille de la piscine. Lorsque votre acteur appelle recevoir , il est dans un état bloqué jusqu'à ce qu'il reçoive son message.
Pour voir l'effet décrit dans les réponses précédentes, vous devez générer plus de deux threads. Cet exemple de programme génère 100 threads avec réception et 100 threads avec réaction.
Lorsque vous l'exécutez, vous pouvez voir que les acteurs de réception occupent chacun un fil, et les réagis partagent un petit nombre de fils. (Il est plus facile de voir quand vous triez la sortie.) la sortie triée dans un programme typique exécuté:
Voir aussi Stackoverflow.com/Questtions/1251666/...