KeyboardInterrupt eats my error and then won't be caught
Philip Semanchuk
philip at semanchuk.com
Sat Jun 20 16:30:58 EDT 2009
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
More information about the Python-list
mailing list