Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5427 > unrolled thread

Re: connect SIGINT to custom interrupt handler

Back to article view | Back to comp.lang.python

Contents

  Re: connect SIGINT to custom interrupt handler Miki Tebeka <miki.tebeka@gmail.com> - 2011-05-15 08:25 -0700
    Re: connect SIGINT to custom interrupt handler Christoph Scheingraber <spam@scheingraber.net> - 2011-05-18 13:28 +0000
      Re: connect SIGINT to custom interrupt handler Jean-Paul Calderone <calderone.jeanpaul@gmail.com> - 2011-05-18 07:16 -0700
        Re: connect SIGINT to custom interrupt handler Nobody <nobody@nowhere.com> - 2011-05-19 11:34 +0100

#5427 — Re: connect SIGINT to custom interrupt handler

Greetings,

> I am trying to connect SIGINT (^c) to a custom interrupt handler like
> this (no threading, just straightforward): 
Why not just catch KeyboardInterrupt?

All the best,
--
Miki

[toc] | [next] | [standalone]

#5693

On 2011-05-15, Miki Tebeka <miki.tebeka@gmail.com> wrote:
> Why not just catch KeyboardInterrupt?

Would it be possible to continue my program as nothing had happened in
that case (like I did before, setting a flag to tell main() to finish the
running data download and quit instead of starting the next data download
{it's a for-loop})?

I have tried it, but after catching the KeyboardInterrupt I could only
continue to the next iteration.

[toc] | [prev] | [next] | [standalone]

#5698

On May 18, 9:28 am, Christoph Scheingraber <s...@scheingraber.net>
wrote:
> On 2011-05-15, Miki Tebeka <miki.teb...@gmail.com> wrote:
>
> > Why not just catch KeyboardInterrupt?
>
> Would it be possible to continue my program as nothing had happened in
> that case (like I did before, setting a flag to tell main() to finish the
> running data download and quit instead of starting the next data download
> {it's a for-loop})?
>
> I have tried it, but after catching the KeyboardInterrupt I could only
> continue to the next iteration.

No, since the exception being raised represents a different flow of
control
through the program, one that is mutually exclusive with the flow of
control
which would be involved with continuing the processing in the
"current"
iteration of your loop.

Setting SA_RESTART on SIGINT is probably the right thing to do.  It's
not
totally clear to me from the messages in this thread if you managed to
get
that approach working.  The most commonly encountered problem with
this
approach is that it means that any blocking (eg I/O) operation in
progress
won't be interrupted and you'll have to wait for it to complete
normally.
In this case, it sounds like this is the behavior you actually want,
though.

Jean-Paul

[toc] | [prev] | [next] | [standalone]

#5771

On Wed, 18 May 2011 07:16:40 -0700, Jean-Paul Calderone wrote:

> Setting SA_RESTART on SIGINT is probably the right thing to do.  It's not
> totally clear to me from the messages in this thread if you managed to get
> that approach working.

He didn't; select() isn't SA_RESTART-able.

Unfortunately, the author of select.select() decided to treat EINTR as an
error. It isn't; it's a "third way", neither success nor failure, similar
to EAGAIN. Normally, you would treat EINTR from select() in the same way
as a timeout.

While it's possible to work around this, the interface encourages getting
it wrong.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web