KeyboardInterrupt eats my error and then won't be caught

[Philip Semanchuk]

On Jun 20, 2009, at 7:41 AM, Piet van Oostrum wrote:

> After my previous experiment I was curious how this works with
> input(). I replaced the sem.acquire() with raw_input() and ran the  
> same
> tests. Now the inner exception is really taken so it works like the OP
> expected. The exception, however is KeyboardInterrupt, not the special
> exception from the IPC module.
>
> So I looked in the source code how they did it:
> The code is in Parser/myreadline.c.
>
> This code for input in function calls PyErr_CheckSignals() and
> PyOS_InterruptOccurred() for a proper handling of the interrupt. So it
> seems the OP should do something similar. Onl;y to deliver the custom
> error you will have to do some other stuff. I don't know what but  
> maybe
> calling PyErr_SetString is sufficient as it might overwrite the
> KeyboardInterrupt stuff.

Thank you Greg and especially Piet for going to the trouble of  
installing posix_ipc and experimenting with it.

Piet, your research into raw_input() gave me a solution.

In my C code, I added a call to PyErr_CheckSignals() as the first line  
inside the "case EINTR". Apparently calling PyErr_CheckSignals() sets  
the Python error indicator -- PyErr_Occurred() returns true and the  
error is PyExc_KeyboardInterrupt. I'm able to clear that error and  
return my own.

Prior to adding the call to PyErr_CheckSignals(), PyErr_Occurred()  
returned false, so my code had no error to clear.

Best of all, PyErr_CheckSignals() doesn't interfere with a Python- 
level signal handler if one is set.

This worked under OS X and Linux.

I'll have to think some more about exactly how I want my module to  
report the Ctrl-C, but at least now I have the tools to control the  
situation.

Thanks again for your invaluable assistance. If I'm ever in NL or NZ  
I'll buy you a beer. =)


Cheers
Philip