[Numpy-discussion] Handling interrupts in NumPy extensions
oliphant at ee.byu.edu
Thu Aug 24 17:38:43 CDT 2006
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
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
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
More information about the Numpy-discussion