Gonzalo, On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger <ellisonbg....@gmail.com> wrote:
> > Gonzalo, > > Thanks for starting this discussion. I am willing to help with this > effort > > as I definitely need this capability. Part of the challenge will be > > figuring out how to do this on Windows. > > Not necessarily. I think signals(2) is part of C89, and setjmp(3) / > longjmp(3) are as well, so they should work on windows (although it's > probably good for trapping ctrl-c and fp exceptions and not much more > -- but what else do you need?). Note that sigsetjmp(3) / siglongmp(3) > don't seem to be part of ansi c, though... I'm not sure atm why we use > that --- possibly only makes sense on unix and those can be changed to > the no-sig counterparts on windows) > > This is encouraging, hopefully it won't be an issue to port this to Windows. > > In terms of syntax, I am not sure that the decorator approach would work. > > The reason the that you probably don't want to enable this for entire > > functions. Because it is such an invasive things, you want it on as > little > > as possible. Thus, I almost think the with syntax would work better: > > with c_signals: > > .... > > I wouldn't call this "invasive". Rather, it's "expensive" to set up > (because of the setjmp). Thus, if a codepath uses this, it's better if > it get's called only once, rather than having several (unnested) pairs > during the execution. In fact, the key about supporting nesting is > that we only setjmp at the outer level. So, for instance, if you have > a function f which loops over a function g, and you know g traps the > signals, then you may be better off (performancewise) to trap signals > in f itself, so g doesn't have to repeatedly call setjmp. > > IOW, the hard part of trapping the signals is not trapping them, but > recovering. Python recovers using the exception handling mechanism, > but for C code that won't work, which is the reason python can't do > anything with the signals when it's running c code. > > To recover, you need to call setjmp() beforehand, at a place where you > know how to recover so you can use longjmp() to actually recover to a > sane state. [setjmp saves the stack context, so longjmp restores, this > is effectively the same as unwinding the stack, except you don't need > support from the intermediate functions as you do in python or c++ > exceptions] > > Thanks for describing this better, it helps me to understand what the current _sig_on/_sig_off does. Because of the licensing issues, I am not looking at the code in Sage until it has been officially re-licensed. Once that has been done, I will dig into the code to see what it actually does. > PS: I'll still try to look at the code and write something more > detailed about it. I feel that would help to decide on what's the sane > syntax/name, since there is a bit of confusion on what _sig_on / > _sig_off actually do. > > Yes, this would be great. > PPS: this seems to be very "ingrained" with the sage inners for > library interfaces, and it's already in there, so it's hard to make a > list of reasons we want to use (e.g. issues we would have otherwise, > features we want it to support, etc). Since you are coming from a > different camp, maybe you can try to list your reasons -- what > problems do you think this would fix for you, and what enhancements > would this bring up. [ok, I know some reasons for sage, but I'm not > listing any to avoid biasing you... ] > > I am not sure I am following what you are asking. Can you elaborate on this question? Thanks! Brian > -- > 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<sage-devel%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- 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
