Erlang. Как передать поток от одного процесса другому?

Question

[Максим Барулин]

Доброго времени суток, Habr!

Есть OTP приложение в нём несколько супервизоров, пусть будет А и Б.
Супервизор А порождает воркера Аа.
Cупервизор Б порождает воркера Ба по запросу от Аа.

Как передать поток управления от Б в Ба, чтобы Аа ожидал ответа от Ба, а не от Б?



Как один из вариантов я рассматриваю переделывание архитектуры приложения, но это будет крайний случай.

Answer 1

[Сергей]

в gen_server есть обработчик
handle_call(Msg, From, State) ->
PidBa ! { Msg, From },
{ noreply, State };

вот этот From -- это есть указатель на того, кто ожидает.
Т.о. вы в Ба должны каким то образом передать этот From.
Далее Ба может ответить:
gen_server:reply(From, Answer).

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

P.S. handle_call вызывается с помощью gen_server:call(Pid, Msg, Timeout).

Более подробно почитать можно тут:
www.erlang.org/doc/man/gen_server.html
а в более популярной форму тут:
learnyousomeerlang.com/clients-and-servers
или по русски в районе этого:
https://github.com/dyp2000/Russian-Armstrong-Erlang

Comments

[Максим Барулин]

За gen_server:reply(From, Answer) спасибо, не знал о такой возможности. Передать не проблема. Но я, скорее всего, пойду немного другим путём. Через метод в Б буду возвращать пид Ба, а из Аа по этому пиду работасть с Ба. Хотя ваш вариант тоже обязательно попробую, так как он позволяет не менять архитектуру.

[Сергей]

Ваш вариант будет на 1 отправку дороже.

[Максим Барулин]

против такого аргумента не попрёшь :)

[Максим Барулин]

Реализовал вот такой вариант https://github.com/Slavenin/simple-server-with-workers но он не работает по вашей схеме. Почему не работает, понятно, из-за использования gen_server:cast/2. Использование gen_server:call/2 приведёт к остановке процесса супервизора до ответа воркера. Если использовать промежуточный процесс, то ситуация будет примерно такая же, только останавливаться будет промежуточный процесс. Основная же идея заключается в прямом связывании процессов Аа и Ба без остановки процессов, т.е. чтобы Аа ждал ответа от Ба, а всё остальное при этом работало. Буду благодарен за указание на то место, где я не прав.

[Сергей]

do_work работает в контесте вызывающего процесса. Т.е. там где вы вызываете do_work -- там он и работает. Супервизор тут не причем.

[Максим Барулин]

Я это прекрасно понимаю. Штука в том, что если вызывать do_work в контексте промежуточного процесса (О), то он точно также будет ждать ответа от Ба, а запросы к нему будут ставиться в очередь.
итеряетяс весь смысл создания воркеров у Б, так как процесс всё-равно будет идти синхронно. Пример того, что должно получаться на картинке:
при этом не важно как идут запросы, через Б или через промежуточный менеджер процессов О, главное, чтобы никто никого не ждал, кроме обращающегося к воркеру процесса.

[Сергей]

O должен быть менеджером процессов и отдавать в Aa PID Ба для использования.
А вообще не изобретайте велосипед есть пулы воркеров, например:
https://github.com/devinus/poolboy

[Сергей]

Или по другому: Aa знает pid O. Он обращается:
gen_server:call(PidO, Msg),

O вызывает gen_server:cast(PidB, { FromA, Msg })

PidB делает gen_server:reply(From, Response)
Результат возвращается в Aa.

[Максим Барулин]

Или по другому: Aa знает pid O. Он обращается:
gen_server:call(PidO, Msg),

O вызывает gen_server:cast(PidB, { FromA, Msg })

PidB делает gen_server:reply(From, Response)
Результат возвращается в Aa.

Работает! Большое спасибо!