On Sat, Mar 13, 2010 at 7:22 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mar 13, 2010, at 4:04 PM, Gonzalo Tornaria wrote: >> What are the options for supporting this (either the >> decorator/function attribute or the with-clause)? > > We can support both. We could support custom signal handlers via something > like > > @cython.setup_signal_handler(some_func_ptr, other_data, ...) > def blah(...): > ...
Great. How does that actually work? Is the decorator somehow modifying the code of blah at compile time, or is a python wrapper produced? Minimal overhead would be if the only difference in the C code is that calls to "_sig_on"/"_sig_off" are added in the entry/exit code, etc. > for ultimate flexibility. It would also help if they were documented > explained better--my understanding of _sig_on and _sig_off is very shallow: > one needs them to be able to interrupt C code, they need to come in pairs, > and doing Python stuff while "holding" the signal is dangerous (though I > think we do it all the time). On that last note, we can actually enforce > pure C inside a sig_on/sig_off block. I'm going to try to write a summary documentation of what's the issue, why we want this, and how it works in original /current / proposed implementation. Keep tuned (it could take me a while, but I don't want to hold this message). > There's also the question of naming--sig_on probably isn't the clearest > name. Definitely. Maybe something like "with trap_signals", since that's more in line with the desired effect: we want certain signals which may be raised during execution of c code to be trapped and raised as exceptions to python. Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
