Scala актеры против потоков и блокировки IO

Как я понимаю, актеры - это в основном легкие потоки, реализованные поверх потоков, запускающие много актеров в небольшом пуле общих потоков.

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

Учитывая, что, как работают актеры, когда вам нужно выполнять такие операции ввода-вывода? Существуют ли операции, которые "actor-block", приостанавливающие действие актера, позволяя потоку перейти к другим операциям (так как блокирующие операции приостанавливают поток, позволяя процессору перейти к другим операциям), или все, что написано на CPS, с цепью актеры? Или актеры просто не подходят для такого рода длительной операции?

Предыстория: у меня есть опыт написания многопоточного материала классическим способом и хорошо понимаю, как работают циклы CPS/event, но не имеют абсолютно никакого опыта работы с актерами и просто хотят понять на высоком уровне, как они вписываются, прежде чем погрузиться в код.

Ответ 1

Это не проблема корректности, потому что библиотека актера будет создавать больше потоков при необходимости (правильно?)

Насколько я понимаю, это неправильно. Актер заблокирован и отправляет ему другое сообщение, заставляя это сообщение сидеть в почтовом ящике действующих лиц, пока этот актер не сможет receive он или react к сообщению.

В программировании в Scala (1) он явно заявляет, что актеры не должны блокироваться. Если актеру нужно что-то делать, он должен передать работу второму актеру, чтобы главный актер мог освободиться и продолжить читать сообщения из своего почтового ящика. Как только работник завершит работу, он сможет подтвердить этот факт основному актеру, который может завершить все, что он должен делать.

Поскольку у рабочих тоже есть почтовые ящики, вы в конечном итоге столкнетесь с несколькими рабочими, работающими по работе. Если у вас недостаточно процессора, чтобы справиться с этим, их очереди будут становиться все больше и больше. В конце концов вы можете масштабировать, используя удаленных участников. Akka может быть более полезным в таких случаях.

(1) Глава 32.5 программирования в Scala (Odersky, Second edition, 2010)

EDIT: Я нашел это:

Метод планировщика признака Actor может быть переопределен для возврата ResizableThreadPoolScheduler, который изменяет размер пула потоков, чтобы избежать голодания, вызванного субъектами, которые вызывают произвольные методы блокировки.

Нашел его по адресу: http://www.scala-lang.org/api/current/scala/actors/Actor.html

Итак, это означает, что в зависимости от установленного планировщика, возможно, пул, используемый для запуска актеров, будет увеличен. Я ошибся, когда сказал, что вы ошибаетесь:-) Остальная часть ответа по-прежнему сохраняется.

Ответ 2

Как все работает в erlang, так это то, что вся операция блокировки должна быть доставлена отправным сообщением, потому что когда ваш актер заблокирован, ожидая сообщения, оно передает поток другому актору.

Итак, если вы хотите сделать некоторые операции блокировки, такие как чтение из файла, вы должны сделать актера FileReader, который использует Non-bloking api для чтения и записи из файла. И пусть ваш другой актер использует этого актера (отправлять и получать сообщение) как api для чтения и записи в файл.