Scala актеры: получить против реагировать

Те заявления о "отбрасывании стека" смутили меня и на некоторое время, и я думаю, что я понял это сейчас, и теперь это мое понимание. В случае "получения" на сообщение выделен выделенный поток потока (с помощью функции object.wait() на мониторе), а это означает, что полный стек потоков доступен и готов к продолжению с точки "ожидания" при получении сообщение. Например, если у вас был следующий код

  def a = 10;
  while (! done)  {
     receive {
        case msg =>  println("MESSAGE RECEIVED: " + msg)
     }
     println("after receive and printing a " + a)
  }

поток будет ждать в принимающем вызове до тех пор, пока сообщение не будет принято, а затем продолжит работу и распечатает сообщение "после приема и печати 10" и со значением "10", которое находится в стеке стека до потока заблокирован.

В случае реакции нет такого выделенного потока, весь метод метода реагирования фиксируется как замыкание и выполняется каким-то произвольным потоком соответствующего актера, получающего сообщение. Это означает, что будут выполняться только те утверждения, которые могут быть записаны как закрытие, и что там, где появляется тип возврата "Nothing". Рассмотрим следующий код

  def a = 10;
  while (! done)  {
     react {
        case msg =>  println("MESSAGE RECEIVED: " + msg)
     }
     println("after react and printing a " + a) 
  }

Если у реагирования был тип возврата типа void, это означало бы, что законно иметь утверждения после вызова "реагировать" (в примере оператор println, который печатает сообщение "после реагирования и печати 10" ), но в действительности это никогда не будет выполнено, поскольку только тело метода "реагирования" захватывается и упорядочивается для выполнения позже (по прибытии сообщения). Поскольку контракт реагирования имеет тип возврата "Ничего", не может быть никаких заявлений после реагирования, и там, где нет причин для поддержания стека. В приведенном выше примере переменная "a" не должна поддерживаться в качестве операторов после того, как ответные вызовы вообще не выполняются. Обратите внимание, что все необходимые переменные с телом реакции уже фиксируются как закрытие, поэтому он может выполняться просто отлично.

Рамка java actor Kilim фактически выполняет техническое обслуживание стека, сохраняя стек, который разворачивается при реагировании на получение сообщения.

Ответ "да" - если ваши участники не блокируют что-либо в вашем коде, а вы используете react, вы можете запустить свою "параллельную" программу в рамках одного потока (попробуйте установить системное свойство actors.maxPoolSize, чтобы узнать).

Одна из наиболее очевидных причин, почему необходимо отказаться от стека вызовов, заключается в том, что в противном случае метод loop завершился бы StackOverflowError. Как бы то ни было, структура довольно умно заканчивает react, бросая SuspendActorException, который улавливается циклом цикла, который затем снова запускает react с помощью метода andThen.

Посмотрите на метод mkBody в Actor, а затем на метод seq, чтобы увидеть, как цикл перестраивается - ужасно умный материал!

Просто для этого:

Программирование на основе событий без инверсии управления

Эти документы связаны с scala api для Актера и обеспечивают теоретические рамки для реализации актера. Это включает в себя, почему реакция никогда не может вернуться.

Я не делал большой работы с scala/akka, однако я понимаю, что существует очень существенное различие в том, как планируются актеры. Акка - это просто умный поток, который накладывает время на выполнение актеров... Каждый раз, когда срез будет исполнением одного сообщения до завершения актером, в отличие от Эрланг, который может быть на инструкцию?!

Это заставляет меня думать, что реакция лучше, поскольку она намекает на текущую цепочку, чтобы рассмотреть других участников для планирования, где, поскольку получение "может" задействовать текущий поток для продолжения выполнения других сообщений для одного и того же актера.