Christoph Scheingraber wrote:
On 2011-05-15, Thomas 'PointedEars' Lahn pointede...@web.de wrote:
Obviously. `signal' refers to an `int' object, probably by something
like
signal = 42
before. E.g. `print' or a debugger will tell you, as you have not showed
the relevant parts of the
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,
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
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
Hi,
I am trying to connect SIGINT (^c) to a custom interrupt handler like
this (no threading, just straightforward):
if __name__ == __main__:
quit = False
def interrupt_handler(signal, frame):
global quit
if not quit:
print blabla, i'll finish my task and quit kind of message
On Sun, 15 May 2011 09:44:04 +, Christoph Scheingraber wrote:
signal.signal(signal.SIGINT, interrupt_handler)
This worked fine in some rare lucky cases, but most of the times, the
module I am using (my university's seismology project) catches the SIGINT
and quits:
select.error: (4,
I now have signal.siginterrupt(signal.SIGINT, False) in the line
below signal.signal(signal.SIGINT, interrupt_handler)
Unfortunately, pressing ^c still results in the same interrupt error. I
also tried putting signal.siginterrupt into the interrupt_handler
function, which gave an interesting
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
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, May 16, 2011 at 12:32 AM, Christoph Scheingraber ch...@spam.org wrote:
I now have signal.siginterrupt(signal.SIGINT, False) in the line
below signal.signal(signal.SIGINT, interrupt_handler)
Unfortunately, pressing ^c still results in the same interrupt error. I
also tried putting
Christoph Scheingraber wrote:
I now have signal.siginterrupt(signal.SIGINT, False) in the line
below signal.signal(signal.SIGINT, interrupt_handler)
Unfortunately, pressing ^c still results in the same interrupt error. I
also tried putting signal.siginterrupt into the interrupt_handler
On 2011-05-15, Thomas 'PointedEars' Lahn pointede...@web.de wrote:
Obviously. `signal' refers to an `int' object, probably by something like
signal = 42
before. E.g. `print' or a debugger will tell you, as you have not showed
the relevant parts of the code.
The problem is that I am
On Sun, 15 May 2011 17:05:57 +, Christoph Scheingraber wrote:
Is it correct anyway to have
signal.siginterrupt(signal.SIGINT, False)
in my custom interrupt_handler function
No.
or should it be outside but after
signal.signal(signal.SIGINT, interrupt_handler)?
Yes.
--
On Sun, 15 May 2011 14:32:13 +, Christoph Scheingraber wrote:
I now have signal.siginterrupt(signal.SIGINT, False) in the line
below signal.signal(signal.SIGINT, interrupt_handler)
Unfortunately, pressing ^c still results in the same interrupt error.
Sorry; I wasn't paying sufficient
13 matches
Mail list logo
