asynchronous - Erlang: diferencia entre usar gen_server: cast/2 y paso de mensaje estándar

gen-server

Question

Estaba trabajando aunque era un problema y noté un código donde un programador anterior estaba pasando mensajes usando la convención estándar de PID. Mensaje. He estado usando gen_server: cast / 2. Me preguntaba si alguien podría explicarme las diferencias y consideraciones críticas al elegir entre los dos.

Answer 1

Además de la publicación de legoscia, diría que es más fácil rastrear API de función dedicada que mensajes. Especialmente en el entorno de producción.

Answer 2

Hay algunas diferencias menores:

• Obviamente, gen_server maneja los moldes en handle_cast y los mensajes "normales" en handle_info .
• Un reparto nunca falla; siempre regresa ok Enviando un mensaje con ! falla con badarg si está enviando un mensaje a un átomo que actualmente no está registrado en un proceso. (Enviar un mensaje a un pid nunca causa un error, incluso si el proceso está muerto.)
• Si gen_server se está ejecutando en un nodo remoto que no está actualmente conectado al nodo local, gen_server:cast generará un proceso en segundo plano para establecer la conexión y enviar el mensaje, y devolver inmediatamente, mientras ! solo regresa una vez que se establece la conexión. (Vea el código para gen_server:do_send .)

En cuanto a cuándo elegir uno u otro, es principalmente una cuestión de gusto. Diría que si el mensaje podría considerarse una función API asíncrona para gen_server, debería usar cast y tener una función API específica en el módulo de devolución de llamada gen_server. Es decir, en lugar de llamar a gen_server:cast directamente, así:

gen_server:cast(foo_proc, {some_message, 42})

hacer una llamada a la función:

foo_proc:some_message(42)

e implementar esa función como el elenco directo anterior. Eso encapsula el protocolo específico de gen_server dentro de su propio módulo.

En mi opinión, los mensajes "simples" se usarían para eventos, a diferencia de las llamadas API. Un ejemplo serían los mensajes del monitor, {''DOWN'', Ref, process, Id, Reason} , y eventos de un tipo similar que podrían ocurrir en su sistema.