Cool, I'll give the patch a shot. It looks like some other projects have a
variable or option for disabling interrupts for exactly this reason; if a
patch works, it might make sense to do signals optionally in Sage.
I'm trying to import the sage libraries into some Django code. I'm playing
with getting a sage-enabled web-framework, which would allow me to do lots
and lots of Sage-things in a webpage using a local installation of Sage
directly, instead of passing through the cell server, for example. Django
has a server which builds up the webpages that you ask for. Then, in the
code that generates a webpage, I'm doing a 'from sage.all import *' to give
access to the Sage libraries. If a subprocess is a better way to do that,
I should look into it...
Thanks for the quick response!
On Friday, March 29, 2013 10:02:25 AM UTC+3, Jeroen Demeyer wrote:
>
> 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.
