Signals in singleton processes

Signals in singleton processes
Prev	Chapter 25. Application singleton design pattern	Next

The first singleton process creates a listening socket in /tmp, that gets registered with the portmapper. Other singleton processes connect to an existing, registered socket.

Filesystem sockets must be explicitly removed. To avoid polluting /tmp, x::singletonapp::create() blocks the following signals: SIGINT, SIGHUP, SIGTERM, and SIGQUIT. A signal handler gets installed to catch these signals.

When any of those signals are received, the singleton process stops accepting any more connections from other application processes, and stops creating new threads, however the destructor in the singleton process cannot terminate until all existing threads terminate, first. It is expected that a receipt of this signal promptly stops all existing threads, at which point the entire singleton process terminates. This may be done in two ways:

If the thread object that's returned by new_thread() inherits from x::stoppableObj, its stop() method gets invoked.
Alternatively, signal handlers may be separately installed, and perform the necessary duties that result in the termination of all threads.
```
x::ref<::obj> mcguffin=x::singletonapp::install_all_sighandlers(
    []
    (int signum)
    {
    });
```
install_all_sighandlers() installs the given handler for all signals that result in the singleton process stopping accepting any new connections. It's expected that the signal handler will make necessary arrangements for all existing threads' swift termination. install_all_sighandlers() uses install_sighandler() to install the given handler for all blocked signals (returning a single mcguffin for all of them).