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