5 messages in org.python.python-bugs-list[ python-Bugs-875692 ] Ctrl-C doesn't...
FromSent OnAttachments
SourceForge.netMar 27, 2004 6:56 am 
SourceForge.netMar 27, 2004 11:00 am 
SourceForge.netMar 27, 2004 2:04 pm 
SourceForge.netMar 28, 2004 2:10 am 
SourceForge.netMar 28, 2004 5:00 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main threadActions...
From:SourceForge.net (nore@sourceforge.net)
Date:Mar 28, 2004 5:00:15 am
List:org.python.python-bugs-list

Bugs item #875692, was opened at 2004-01-12 21:37 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment: [forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is related to 846817?

I'm trying to do some basic threading with Python. However, there are times when Ctrl-C fails to cause a KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As written, I cannot interrupt it with Ctrl-C (nothing happens even if I hold it down). If I uncomment the print statement in the main thread, then I can interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives the main thread a "chance to run" where it finally notices the signal from the Ctrl-C. However, I shouldn't have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on Fedora and some others, so I'm posting it here (maybe some problem with Debian's libc6?).

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)

Date: 2004-03-28 10:00

Message: Logged In: YES user_id=60903

with the patch applied the example exits usually on the second or third keystroke, never on the first ^C.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky) Date: 2004-03-28 07:10

Message: Logged In: YES user_id=55188

Here's my patch. Please review/test it. :)

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky) Date: 2004-03-27 19:04

Message: Logged In: YES user_id=55188

Nah. For my some investigation, it doesn't seem to be a problem of GNU readline.

On my debian machine, main for loop of ceval.c:eval_frame switches threads context for every periodic loops. Because main threads is just running time.sleep(), it goes in this way:

1) context switches to sub thread by time.sleep() 2) entering periodic if-block and resets _Py_Tick to 100. 3) because main thread has only 1 line that runs time.sleep(), _Py_Tick is always 97~99 for main thread. 4) goto 1)

So, Py_MakePendingCalls() will never be called from main thread. As a result, Ctrl-C doesn't work.

Hmm. I don't have a fix for right now. How about to make per-thread _Py_Tick?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one) Date: 2004-03-27 16:00

Message: Logged In: YES user_id=31435

Ctrl+C interrupts it on Win98SE -- upgrade to a real OS <wink>. When odd cmdline behavior is seen on a Unixish box, staring at (try with and without) GNU readline is a good experiment.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus) Date: 2004-03-27 11:56

Message: Logged In: YES user_id=12364

I use debian and can reproduce it. Python package version 2.3.3-6. I also tried with python 2.2 and the bug was NOT present. Package version 2.2.3-9.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh) Date: 2004-01-13 11:16

Message: Logged In: YES user_id=6656

As the guy says in the bug report, the comp.lang.python opinion was that this was a problem in debian! Can someone with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------