On OpenBSD, SIGINT handling in the REPL is delayed until further input:

Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>>  <= here Ctrl-C is pressed but nothing appears
Only after hitting <Return> a traceback appears:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt


This behavior was introduced (exposed by?) r68460.


When Python is compiled without threads, the behavior is normal.

The bug is also present with Python 3.1 on OpenBSD 4.7-current.

> This behavior was introduced (exposed by?) r68460.

After a quick look, I don't see anything wrong with r68460, but it might very well have exposed this problem which was lurking before.

> When Python is compiled without threads, the behavior is normal.

We've already had some problems - especially on *BSD - when mixing signals and threads (and it might be even worse on OpenBSD, since pthreads are implemented in user-space). However, IIUC, in this case you only have a single thread, right?

Could you post the output of an strace (well, ktrace on OpenBSD)?
Is Python compiled with readline support?

I know, the OpenBSD libpthread has problems. I listed some possible
candidates in #8712.

For instance:

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/python/2.6/patches/Attic/patch-Lib_test_test_signal_py?rev=1.3;content-type=text%2Fplain


The comment says: "siginterrupt not reliable (does not mix well with threading"



To answer your questions:

1) Yes, there is only a single thread.

2) I only have an old OpenBSD 4.5, so it's not so useful to test
   there; I know Philip Guenther fixed some libpthread problems
   in the meantime.

I forgot: readline support is enabled, and there are known problems:

http://marc.info/?t=128327329300003&r=1&w=2