/* Signal handling: This header file defines macros that allow your code to handle interrupts received during processing. Interrupts that could reasonably be handled: SIGINT, SIGABRT, SIGALRM, SIGSEGV ****Warning*************** Do not allow code that creates temporary memory or increases reference counts of Python objects to be interrupted unless you handle it differently. ************************** The mechanism for handling interrupts is conceptually simple: - replace the signal handler with our own home-grown version and store the old one. - run the code to be interrupted -- if an interrupt occurs the handler should basically just cause a return to the calling function for finish work. - restore the old signal handler Of course, every code that allows interrupts must account for returning via the interrupt and handle clean-up correctly. But, even still, the simple paradigm is complicated by at least three factors. 1) platform portability (i.e. Microsoft says not to use longjmp to return from signal handling. They have a __try and __except extension to C instead but what about mingw?). 2) how to handle threads: apparently whether signals are delivered to every thread of the process or the "invoking" thread is platform dependent. --- we don't handle threads for now. 3) do we need to worry about re-entrance. For now, assume the code will not call-back into itself. Ideas: 1) Start by implementing an approach that works on platforms that can use setjmp and longjmp functionality and does nothing on other platforms. 2) Ignore threads --- i.e. do not mix interrupt handling and threads 3) Add a default signal_handler function to the C-API but have the rest use macros. Simple Interface: In your C-extension: around a block of code you want to be interruptable with a SIGINT NPY_SIGINT_ON [code] NPY_SIGINT_OFF In order for this to work correctly, the [code] block must not allocate any memory or alter the reference count of any Python objects. In other words [code] must be interruptible so that continuation after NPY_SIGINT_OFF will only be "missing some computations" Interrupt handling does not work well with threads. */ /* Add signal handling macros Make the global variable and signal handler part of the C-API */ #ifndef NPY_INTERRUPT_H #define NPY_INTERRUPT_H #ifndef NPY_NO_SIGNAL #include #include #ifndef sigsetjmp #define SIGSETJMP(arg1, arg2) setjmp(arg1) #define SIGLONGJMP(arg1, arg2) longjmp(arg1, arg2) #define SIGJMP_BUF jmp_buf #else #define SIGSETJMP(arg1, arg2) sigsetjmp(arg1, arg2) #define SIGLONGJMP(arg1, arg2) siglongjmp(arg1, arg2) #define SIGJMP_BUF sigjmp_buf #endif # define NPY_SIGINT_ON { \ PyOS_sighandler_t _npy_sig_save; \ _npy_sig_save = PyOS_setsig(SIGINT, _PyArray_SigintHandler); \ if (SIGSETJMP(*((SIGJMP_BUF *)_PyArray_GetSigintBuf()), \ 1) == 0) { \ # define NPY_SIGINT_OFF } \ PyOS_setsig(SIGINT, _npy_sig_save); \ } #else /* NPY_NO_SIGNAL */ # define NPY_SIGINT_ON # define NPY_SIGINT_OFF #endif /* HAVE_SIGSETJMP */ #endif /* NPY_INTERRUPT_H */