Catching control-C

[MCIPERF]

On Jul 9, 7:28 pm, Miles Kaufmann <mile... at umich.edu> wrote:
> On Jul 9, 2009, at 9:20 AM, Lie Ryan wrote:
>
> > Michael Mossey wrote:
> >> I want to understand better what the "secret" is to responding to a
> >> ctrl-C in any shape or form.
>
> > Are you asking: "when would the python interpreter process
> > KeyboardInterrupt?"
> > ...
> > In single threaded python program, the currently running thread is
> > always the main thread (which can handle KeyboardInterrupt). I believe
> > SIGINT is checked at every ticks. But SIGINT cannot interrupt atomic
> > operations (i.e. it cannot interrupt long operations that takes a  
> > single
> > tick).
>
> Some otherwise atomic single-bytecode operations (like large integer  
> arithmetic) do manual checks for whether signals were raised (though  
> that won't help at all if the operation isn't on the main thread).
>
> > I believe a tick in python is equivalent to a single bytecode, but
> > please correct me if I'm wrong.
>
> Not all opcodes qualify as a tick.  In general, those opcodes that  
> cause control to remain in the eval loop (and not make calls to other  
> Python or C functions) don't qualify as ticks (but there are  
> exceptions, e.g. so that while True: pass is interruptible).  In  
> Python/ceval.c: PyEval_EvalFrameEx(), those opcodes that don't end in  
> goto fast_next_opcode are ticks.
>
> Please correct me if _I'm_ wrong! :)
> -Miles

You don't need to do I/O.

This works:

try:
   process_forever()
except KeyboardInterrupt:
   save critical stuff
   write nice messages

I often wrap a large computational task like this, with the idea that
the exception can let me exit safely, in my case by writing restart
parameters and printing a summary pf progress to date.

Gerry