gerard.blais at gmail.com
Wed Jul 15 20:40:32 CEST 2009
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! :)
You don't need to do I/O.
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.
More information about the Python-list