v18 pre-release discussion

[ewmayer]

One of my main beta testers, GordP, has convinced me to add signal-catching (e.g. instead of just dying on ctrl-c, complete the current iteration, write savefiles and exit gracefully) to the v18 code upgrades - I have that working, the remaining question is which of the standard set of signals - that is, the catchable ones thereof - the program should listen for. On my Mac, 'man signal' offers the following smorgasbord:

1     SIGHUP       terminate process    terminal line hangup
2     SIGINT       terminate process    interrupt program
3     SIGQUIT      create core image    quit program
4     SIGILL       create core image    illegal instruction
5     SIGTRAP      create core image    trace trap
6     SIGABRT      create core image    abort program (formerly SIGIOT)
7     SIGEMT       create core image    emulate instruction executed
8     SIGFPE       create core image    floating-point exception
9     SIGKILL      terminate process    kill program
10    SIGBUS       create core image    bus error
11    SIGSEGV      create core image    segmentation violation
12    SIGSYS       create core image    non-existent system call invoked
13    SIGPIPE      terminate process    write on a pipe with no reader
14    SIGALRM      terminate process    real-time timer expired
15    SIGTERM      terminate process    software termination signal
16    SIGURG       discard signal       urgent condition present on socket
17    SIGSTOP      stop process         stop (cannot be caught or ignored)
18    SIGTSTP      stop process         stop signal generated from keyboard
19    SIGCONT      discard signal       continue after stop
20    SIGCHLD      discard signal       child status has changed
21    SIGTTIN      stop process         background read attempted from control terminal
22    SIGTTOU      stop process         background write attempted to control terminal
23    SIGIO        discard signal       I/O is possible on a descriptor (see fcntl(2))
24    SIGXCPU      terminate process    cpu time limit exceeded (see setrlimit(2))
25    SIGXFSZ      terminate process    file size limit exceeded (see setrlimit(2))
26    SIGVTALRM    terminate process    virtual time alarm (see setitimer(2))
27    SIGPROF      terminate process    profiling timer alarm (see setitimer(2))
28    SIGWINCH     discard signal       Window size change
29    SIGINFO      discard signal       status request from keyboard
30    SIGUSR1      terminate process    User defined signal 1
31    SIGUSR2      terminate process    User defined signal 2

[Mark Rose]

I would have SIGTERM terminate gracefully. SIGINT should terminate gracefully, but terminate expediently if another SIGINT is received (mfaktc has this behaviour). SIGHUP, SIGKILL and SIGPIPE should terminate expediently.

SIGUSR1 and SIGUSR2 are often used to cause a process to reread configuration files or to gracefully restart.

[preda]

On Linux on Ctrl-C I get SIGINT, and that's what I use to stop gracefully.

[retina]

CTRL-\ sends a SIGQUIT in Linux terminals. Ping uses this to display the current statistics and continues to run.

[ewmayer]

Originally Posted by Mark Rose

I would have SIGTERM terminate gracefully. SIGINT should terminate gracefully, but terminate expediently if another SIGINT is received (mfaktc has this behaviour). SIGHUP, SIGKILL and SIGPIPE should terminate expediently.

How does one listen for multiple SIGINTs (ctrl-c) in succession? Should one also define some pause-for-X-milliseconds-after-first-SIGINT delay to listen for a second SIGINT rather than performing an immediate savefiles-and-exit?

[TheJudger]

Hi

Originally Posted by ewmayer

How does one listen for multiple SIGINTs (ctrl-c) in succession? Should one also define some pause-for-X-milliseconds-after-first-SIGINT delay to listen for a second SIGINT rather than performing an immediate savefiles-and-exit?

just add a counter to your signal handler. Hint: on Windows you have to re-register your signal handler once it was triggered.

Oliver

[GP2]

Originally Posted by Mark Rose

I would have SIGTERM terminate gracefully. SIGINT should terminate gracefully, but terminate expediently if another SIGINT is received (mfaktc has this behaviour). SIGHUP, SIGKILL and SIGPIPE should terminate expediently.

SIGUSR1 and SIGUSR2 are often used to cause a process to reread configuration files or to gracefully restart.

As far as I know, SIGKILL can't be caught at all.

The behavior of SIGINT you describe is specific to mfaktc because one CTRL-C means "stop after finishing this factor class", which may take a while, and a second CTRL-C means "no, really stop right now". With programs like mprime and Mlucas, normally writing out an LL or PRP savefile is extremely quick, just a few dozen MB, so the issue doesn't really arise, unless maybe you have a problem with a networked file system.

SIGHUP should terminate gracefully. It probably just means that your terminal session ended while the program was running. For instance if you are running a program in an ssh terminal window on your PC, and your PC went to sleep from inactivity. You can avoid that happening by running the program in screen or a similar utility, or by remembering to run the program with nohup (or run disown on the program if it's running in the background).

Probably everything should just terminate gracefully, because "graceful" and "expedient" amount to the same thing here. All you have to do is write out a small savefile, and there's no reason not to unless you have some reason to believe your data has become corrupted and should not be saved.

[Mark Rose]

Originally Posted by GP2

Probably everything should just terminate gracefully, because "graceful" and "expedient" amount to the same thing here.

Yeah. I'm thinking the difference is finishing a calculation round rather than interrupting it.

[kladner]

Originally Posted by Mark Rose

Yeah. I'm thinking the difference is finishing a calculation round rather than interrupting it.

That has always been my understanding. What I have not understood is the urgency to quit the program. I think that work on the current class is lost in an immediate shutdown. Unless the per-class time is really inconveniently long, why not let it finish?

Originally Posted by preda

On Linux on Ctrl-C I get SIGINT, and that's what I use to stop gracefully.

If you run multiple instances of a program, for example gpuowl, there is another way to stop the running instances:

pkill -int openowl

will stop all instances of openowl gracefully letting them save checkpoints.

[ewmayer]

I've fiddled the code to catch SIGINT, SIGTERM and SIGHUP, print info re. the caught signal and exit gracefully. Users can still use ctrl-\ to force immediate-exit or ctrl-z to suspend the process followed by 'kill [pid]'. There is no multiple-signals-in-a-row handling, I just don't see the need for it in the context of the kind of work Mlucas does.