Chapter 19: Process Supervision, Heartbeats, and IPC Synchronization

This chapter describes the responsibility boundaries of process launch, daemonization, shared-memory heartbeats, and System V semaphores.

1. Responsibilities of Process, HBSystem, and csemp

Class	Purpose	Not
`Process`	fork/exec or run a callable; optionally restart after exit	Not full daemonization
`HBSystem`	Register processes in shared memory, renew heartbeats, detect, terminate, and restart	Not a cross-host registry
`csemp`	System V semaphore for inter-process exclusion	Not a thread mutex

2. Process::startProcess

// sec=-1: start once.
Process::startProcess(
    "/usr/local/bin/worker",
    -1,
    "worker", "--port", "9000");

// sec=3: restart the callable three seconds after each exit.
Process::startProcess([] { runWorker(); }, 3);

The helper does not call setsid(), change directory, set umask, or redirect standard streams. It is process launch/supervision, not traditional Unix daemonization. systemd, containers, or a dedicated supervisor are still preferred in production.

3. HBSystem heartbeat flow

The service calls join() with its path, PID, and up to three arguments.
The service calls renew() periodically.
A separate monitor calls HBCheck(sec).
On timeout, the monitor sends SIGTERM (15) and waits eight seconds. A process that remains alive receives SIGKILL (9), after which the recorded process is restarted.

Current limits: fixed System V IPC key 0x5095, up to 1000 records, fixed argument buffers, and at most three arguments. Distinct IPC keys provide isolation between independent groups on one host.

4. Inter-process semaphore

csemp lock;
if(!lock.init(0x6001))
    return 1;

lock.wait();
// Access a resource shared by processes.
lock.post();

// Resource destruction remains with the owner.
lock.destroy();

5. Shutdown behavior

A supervised service uses the graceful-shutdown model from Chapter 17. SIGKILL (9) cannot be caught and remains the final fallback.

Process supervision demo →