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) > 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] > Thoughts? > Cheers, > Brian Best, Gonzalo 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. 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... ] -- 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
