CoCoA » CoCoA-5

Remember that a (portable) signal handler cannot do much.

Christof was puzzled when running some Normaliz tests through CoCoA-5: he wanted to stop the (long) computation, but found that ctrl-C was just ignored.

One possibility is to restore the default signal handler when calling functions from an external library; this means that the external library decides how to handle the signal.

Upon returning from the external library the CoCoA-5 signal handler should be reinstated.

How does a call to an external lib know that it is inside CoCoA interpreter?

Perhaps the best solution would be to leave the code as it is, and to write better documentation. After all a call to GMP is a call to an external lib; and some calls can be quite long.

Another possible (simple) approach is to offer a command line flag which stops CoCoAInterpreter from intercepting signals; this means that a ctrl-C (equiv. SIGINT) would immediately kill the process, losing all data computed so far.

Actually, it could make sense not to intercept signals if the interpreter is in "batch mode" (i.e. taking input from a file rather than a terminal).

Christof has tried some experiments with GAP, and he noticed that a single ctrl-C appeared to do nothing, but 2 ctrl-C within a second caused the program to abort (with a message explaining that it had received 2 ctrl-C within a second).

We must look up to see what a (portable) signal handler can do.

I recall also that a long G-basis computation cannot be interrupted with ctrl-C (equiv. SIGINT); instead you have to use a stronger signal such as SIGKILL.

I have found this web page which gives some advice:
http://stackoverflow.com/questions/103280/portable-way-to-catch-signals-and-report-problem-to-the-user

Here is another web site:
http://www.cplusplus.com/forum/unices/16430/

This second site suggests that sigaction is better than signal for specifying the handler; if so, we will have to make some minore changes to src/CoCoA-5/Main.C.

• each time ctrl-C is received a counter is increased
• if the CoCoA interpreter handles the interrupt, it resets the counter to zero
• if the counter is increased to 2, it triggers printing a message saying that one more ctrl-C will kill the process
• if the counter is increased to 3 or greater than the process terminates (perhaps by calling _Exit()?)

This is really rather complicated for a signal handler, so may not be portable (but it probably is).

Do you think this is a reasonable solution?

I could try mimicking GAP but taking note of when the last ctrl-C was received, and allowing increasing beyond 2 only if the last ctrl-C was not long ago (e.g. 1-2secs)

GNU has some useful looking documentation:
http://www.gnu.org/software/libc/manual/html_node/Signal-Sets.html#Signal-Sets
http://www.gnu.org/software/libc/manual/html_node/Sigaction-Function-Example.html

I noticed some example using write instead of cerr << ...; supposedly it is safer, but it looks to be a real hassle :-(