[Numpy-discussion] Handling interrupts in NumPy extensions

David Cournapeau david at ar.media.kyoto-u.ac.jp
Thu Aug 24 22:11:26 CDT 2006

Travis Oliphant wrote:
> 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
> [code]
> 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.
I am not sure whether there are other solutions... This is the way I saw 
signal handling done in common programs when I looked for a solution for 
my matlab extensions.
> 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.
If the library does nothing w.r.t signals, then you just have to clean 
all the things related to the library once
you caught a signal. This is no different than cleaning your own code. 
Actually, cleaning libraries is the main reason why I implemented this 
signal scheme in matlab extensions, since they cannot use the matlab 
memory allocator, and because they live in the same memory space, 
calling several times the same extension can corrupt really quickly most 
of matlab memory space.

Maybe there are some problems I am not aware of ?


More information about the Numpy-discussion mailing list