how release_handler handles new processes that are started during upgrade process?

Questions / Help
,
1

Assume that we want to hot-reload a gen_server module, with changes to the internal state.

So the appup will contain this instruction: {update, ch3, {advanced, []}}

As I understand it, during hot code loading release handler will perform the following steps:

  1. Traverse the supervision tree and collect all the processes that use the module ch3.
  2. Suspend all these processes using sys:suspend.
  3. Load the new module version.
  4. Call code_change callback on all processes.
  5. Resume the processes using sys:resume.

However, it looks like this will run into a problem if a new process with this module is started during step 1 or step 2. For example:

  1. We traverse the supervision tree and collect pids.
  2. New process is started with the old version of the module (say PID <0.1234.0>). This process is not included in the list of processes to update.
  3. Release handler suspends the processes in the list, loads the new module version, runs the code change and resumes.
  4. But that <0.1234.0> process is not included, and so it will crash when old module version is purged.

How is this situation handled? Is there something that release handler does to prevent it, or are these straggling processes simply left to crash and restart the usual way?

2

So I went and read through release_handler code, and the answer to my question is “these straggling processes are simply left to crash and restart the usual way”.

It’s explicitly noted in the comments of release_handler_1:suspend function:

%% Unfortunately, we might end up
%% with the situation that after this suspendation, some new
%% processes start before we have loaded the new code, and these
%% will execute the old code. These processes could be terminated
%% later on (if the prev current version is purged). The same
%% goes for processes that didn’t respond to the suspend message.