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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
