KeyboardInterrupt vs extension written in C

Jp Calderone exarkun at divmod.com
Sat Oct 22 16:46:05 EDT 2005


On 22 Oct 2005 22:02:46 +0200, Dieter Maurer <dieter at handshake.de> wrote:
>"Tamas Nepusz" <ntamas at gmail.com> writes on 20 Oct 2005 15:39:54 -0700:
>> The library I'm working on
>> is designed for performing calculations on large-scale graphs (~10000
>> nodes and edges). I want to create a Python interface for that library,
>> so what I want to accomplish is that I could just type "from igraph
>> import *" in a Python command line and then access all of the
>> functionalities of the igraph library. Now it works, except the fact
>> that if, for example, I start computing the diameter of a random graph
>> of ~100000 nodes and ~200000 edges, I can't cancel it, because the
>> KeyboardInterrupt is not propagated to the Python toplevel (or it isn't
>> even generated until the igraph library routine returns).
>
>Python installs a "SIGINT" handler that just notes that
>such a signal was received. The note is handled during
>bytecode execution. This way, Python handles the (dangerous)
>asynchronous signal synchronously (which is much safer).
>But, it also means that a signal during execution of your C extension
>is only handled when it finished.
>
>What you can do in your wrapper code:
>
>   Temporarily install a new handler for "SIGINT" that
>   uses "longjmp" to quit the C extension execution when
>   the signal occurs.
>
>   Note that "longjmp" is dangerous. Great care is necessary.
>
>   It is likely that SIGINT occurrences will lead to big
>   resource leaks (because your C extension will have no
>   way to release resources when it gets quit with "longjmp").
>

Note that swapcontext() is probably preferable to longjmp() in almost all circumstances.  In cases where it isn't, siglongjmp() definitely is.

Jp



More information about the Python-list mailing list