
Getting started with OTP: creating process families - kansi
https://medium.com/@kansi/getting-started-with-otp-creating-psycho-families-b4f6ce01d1e4#.68pprpxgj
======
simoncion
Mods: the article's title is "Getting started with OTP: creating psycho
families !".

The title of the HN submission doesn't make much sense, considering the
material. I was expecting a discussion of pg2 [0] or similar.

The article's title is apropos, because in Erlang parents often kill their
children and vice-versa.

[0] [http://erlang.org/doc/man/pg2.html](http://erlang.org/doc/man/pg2.html)

------
w8rbt
OTP is an overloaded term, one-time pads, one-time passwords, etc. This one is
Open Telecommunications Platform.

~~~
seiji
Yeah, OTP is an awful name because it's meaningless in the context of
programming without reading history from the 1980s. It should really just be
called "erlang library frameworks" or something similarly sensible.

This article is largely a copy/paste/reword job from the official erlang docs
([http://www.erlang.org/doc/design_principles/gen_server_conce...](http://www.erlang.org/doc/design_principles/gen_server_concepts.html))
too.

~~~
simoncion
I dunno. Something called "Open Telecom Platform" sounds very stodgy and
reliable to me. :)

------
jeffdavis
If you start a service, it's just one process, right? So if it fails, all
pending requests will fail, right?

What is the recommended way to contain a failure to a single request?

~~~
simoncion
> If you start a service, it's just one process, right?

If you search for "So we will create a module named ch3 with gen_server
behaviour", you'll see the author's server code. His server code makes use of
the gen_server behavior.

To answer your questions:

Yes. If the author's server process crashed, all pending requests would be
lost. From what I can tell, gen_servers use the Erlang process mailbox to
maintain a queue of (among other things) requests to be serviced. If a process
dies, its mailbox is destroyed and its contents lost.

If _I_ were concerned about my code's ability to survive a crash of one of its
operations, I would either

* Wrap the operation in a try/catch block that _only_ handled all of the error conditions that I was expecting to encounter.

* Execute the operation in a separate, monitored [0] process that sends a message back with the results of the operation. [1]

Each method has its place, but I would find myself using the child process
method most of the time. Defensive coding is a _really_ bad code smell in
Erlang programs. Swallowing _all_ exceptions is _definitely_ a very defensive
thing to do.

[0] Any process in an Erlang system can monitor any other process in the
system and get a notification when the monitored process terminates.

[1] You can even tell your supervisor to start the process for you so that it
knows about it and can terminate the child if the supervisor is asked to
shutdown.

