On 26/06/2012 20:02, Terry Reedy wrote:
On 6/26/2012 6:51 AM, Devin Jeanpierre wrote:
The issue is that sometimes, if you press ctrl-c on Windows, instead
of raising a KeyboardInterrupt, Python will exit completely. Because
of this, any program that relies on ctrl-c/KeyboardInterrupt is not
I can confirm that there is a race condition between the code in
myreadline.c and the signal_handler. I have a patch in readiness which
basically loops until the signal has been tripped.
But what I don't know is: what to do if the signal *still* doesn't trip
(after 100 millisecond-retries)?
Hi guys,
I just wanted to bring some more attention to issue #1677 , because I
feel it's important and misunderstood. See:
http://bugs.python.org/issue1677
The issue is that sometimes, if you press ctrl-c on Windows, instead
of raising a KeyboardInterrupt, Python will exit completely. Because
of
On 26/06/2012 11:51, Devin Jeanpierre wrote:
Hi guys,
I just wanted to bring some more attention to issue #1677 , because I
feel it's important and misunderstood. See:
http://bugs.python.org/issue1677
The issue is that sometimes, if you press ctrl-c on Windows, instead
of raising a
I just wanted to bring some more attention to issue #1677 , because I
feel it's important and misunderstood.
Please consider working even more on a solution then. If I had time to
work on this, I'd run Python in a debugger, and see what happens. Finding
out in what state Python is when it stops
On 26/06/2012 11:59, Tim Golden wrote:
On 26/06/2012 11:51, Devin Jeanpierre wrote:
Hi guys,
I just wanted to bring some more attention to issue #1677 , because I
feel it's important and misunderstood. See:
http://bugs.python.org/issue1677
The issue is that sometimes, if you press ctrl-c
On 6/26/2012 6:51 AM, Devin Jeanpierre wrote:
The issue is that sometimes, if you press ctrl-c on Windows, instead
of raising a KeyboardInterrupt, Python will exit completely. Because
of this, any program that relies on ctrl-c/KeyboardInterrupt is not
guaranteed to work on windows. Also,
