Fwd: Re: [CRIU] Signalling processes before CRIU/after unCRIU

[Alex/AT]

> When we dump a container should we make sure systemd knows how to talk
> to the rest of the zoo? This sounds ... strange.
Yep. And determination of "parent" may be non-trivial too. It is probably
best to be left to the user to signal the "parent" process.

When we suspend a large tree from the parent, all the child processes
should got signalled before suspending, and be waited for each one to
respond (or not respond). Each one may be execution-halted after getting
response, and then all the non-responding processes in the tree should be
execution-halted at once.

> Frankly, I don't want to re-invent TCP for such a simple case.
It's not even needed. You were thinking about library mechanism, and that
is the best way in terms of predictability.

So it gets to the simple way.

Suspension:

1. Check, if each process in the tree (starting from user specified
process) has "START SUSPEND" callback. If not, postpone suspension until
all processes having callbacks are halted (step 3).
2. For each process with the callback:
2A. Flag the process as "IN SUSPEND"
2B. Enter "START SUSPEND" callback. Return code from "START SUSPEND" may
specify, if the process wants to do some housekeeping, or be postponed to
the step 3.
2C. Wait for the "COMPLETE" callback to be called by the process. On
"COMPLETE" call, execution-halt the process.
2D. Processes that have not responded in given time (user-specified) get
to the step 3.
3. Execution-halt and suspend each process postponed in steps 1 or 2D.

Unsuspension:

1. For all the processes:
1A. Restore process, and unmark its "IN SUSPEND" mode.
1B. Execution-start them. This returns from "COMPLETE" call on all the
processes inside "COMPLETE" callback.

"COMPLETE" callbacks from processes not marked as "IN SUSPEND" should be
ignored. Such calls may be made by processes timed out to housekeep in
step 2D, and suspended while in housekeeping.


-- 
Regards,
Alexey Asemov