On 03/28/2013 11:44 PM, tom d wrote:
The problem seems to be at:
from sage.ext.c_lib import _init_csage, sig_on_count
_init_csage()
which is explicitly using the signal library and doing signal handling
stuff for Sage. Any idea how deep this goes? Some of the online
suggestions are about using some different libraries for signal
handling, which might be a bit more sensitive about whether Sage is the
main process or not.
You could completely disable the Sage signal handler, I guess the
following patch would do it (NOT TESTED!)
diff --git a/c_lib/src/stdsage.c b/c_lib/src/stdsage.c
--- a/c_lib/src/stdsage.c
+++ b/c_lib/src/stdsage.c
@@ -48,7 +48,6 @@
void init_csage() {
init_global_empty_tuple();
init_memory_functions();
- setup_sage_signal_handler();
setup_NTL_error_callback(global_NTL_error_callback, NULL);
}
diff --git a/sage/ext/c_lib.pyx b/sage/ext/c_lib.pyx
--- a/sage/ext/c_lib.pyx
+++ b/sage/ext/c_lib.pyx
@@ -37,8 +37,6 @@
# call its interrupt handler (which is the one we set now). This
# handler issues a sig_check() which finally raises the
# KeyboardInterrupt exception.
- import signal
- signal.signal(signal.SIGINT, sage_python_check_interrupt)
init_csage()
But seriously: why are you trying to run Django and Sage in the same
process? That seems like asking for trouble. Couldn't you run a Sage
subprocess?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
