[Numpy-discussion] Handling interrupts in NumPy extensions

[Travis Oliphant]

David Cournapeau wrote:

>>>I'm working on some macros that will allow extensions to be 
>>>"interruptable" (i.e. with Ctrl-C).  The idea came from SAGE but the 
>>>implementation is complicated by the possibility of threads and making 
>>>sure to handle clean-up code correctly when the interrupt returns.
>>>
>>>      
>>>
>This is funny, I was just thinking about that yesterday. This is a major 
>problem when writing C extensions in matlab (the manual says use the 
>matlab allocator instead of malloc/new/whatever, but when you call a 
>library, you cannot do that...).
>  
>
I'm glad many people are thinking about it.    There is no reason we 
can't have a few ways to handle the situation.

Currently in SVN, the simple

NPY_SIGINT_ON
[code]
NPY_SIGINT_OFF

approach is implemented (for platforms with sigsetjmp/siglongjmp).

You can already use the approach suggested:

if (PyOS_InterruptOccurred()) goto error

to handle interrupts.  The drawback of this approach is that the loop 
executes more slowly because a check for the interrupt occurs many times 
in the loop which costs time.

The advantage is that it may work with threads (I'm not clear on whether 
or not PyOS_InterruptOccurred can be called without the GIL, though).

>I think the case proposer by Perry is too restrictive: it is really 
>common to use external libraries which we do not know whether they use 
>memory allocation inside the processing, and there is a need to clean 
>that too.
>  
>

If nothing is known about memory allocation of the external library, 
then I don't see how it can be safely interrupted using any mechanism.

What is available now is sufficient.  I played far too long with how to 
handle threads, but was not able to come up with a solution, so for now 
I've punted.

-Travis