> 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.
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.