Christoph Scheingraber wrote:
> On 2011-05-15, Thomas 'PointedEars' Lahn 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.
>
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.
Unfortunatel
On May 18, 9:28 am, Christoph Scheingraber
wrote:
> On 2011-05-15, Miki Tebeka 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 d
On 2011-05-15, Miki Tebeka 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'
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
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.
--
htt
On 2011-05-15, Thomas 'PointedEars' Lahn 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 running someon
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 Mon, May 16, 2011 at 12:32 AM, 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.siginte
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
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 resul
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: (
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 messag
13 matches
Mail list logo
