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 > > 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. > 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 ? David ------------------------------------------------------------------------- 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
