<div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Nils Bruin</b> <span dir="ltr"><<a href="mailto:nbruin@cecm.sfu.ca">nbruin@cecm.sfu.ca</a>></span><br>Date: Sat, Feb 26, 2011 at 3:34 AM<br>

Subject: Re: [Ecls-list] Making an external signal handler play nice with embedded ECL<br>To: Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>><br>

<br><br>Dear Juanjo,<br>
<br>
Thank you! That is really useful feedback. The *current* way of running ECL code inside sage is by not enabling signals at all, so that's safe.<br>
I did not quite understand the mprotect trick first but I think I do now. Let me verify:<br>
 - If the ECL signal handler finds that the interrupted code is not "safe", then the handler stores the signal information and marks "env" read-only.<br>
 - The next time "env" is accessed, a SIGSEGV will be triggered, which the ECL signal handler recognises as being triggered by the mprotected region.<br>
<br>
Q: Is it guaranteed that this will happen in a "safe" area or is it possible that the signal handler discovers that it is still not safe and hence leaves the queue as is?<br>
<br>
 - If safe, the handler now processes the queued signals and we're done.<br>
<br>
I think I have a reasonably robust solution now, based on swapping the SIGINT and SIGSEGV handlers between ECL's own and the sage handlers.<br>
<br>
[it's on <a href="http://trac.sagemath.org/sage_trac/ticket/10818" target="_blank">http://trac.sagemath.org/sage_trac/ticket/10818</a> on the off chance you want to refer to the code/point other people to solutions]<br>


<br>
It still leaves a small window where ECLs handlers are in place but ECLs environment isn't yet. If it would be possible to set the ECL signal handlers to "queue, don't handle" before entering ECL and enable them once the ECL environment is in place it might be possible to remove this one glitch.<br>


<br>
Also, this solution would probably not work very well for lots of very small calls into ECL, due to the overhead of all the sigaction calls. I don't think this is much of an issue at the moment, but if it were I imagine the proper solution would be to make sage's signal handler ECL-aware and take appropriate action there (and hooks in the ECL API would help for that)<br>


<br>
In fact, ECL does seem to have a small race condition itself (as most programs seem to have): If I run ECL (stand-alone) and truly bombard it with SIGINTs, I get a segfault.<br>
<br>
With "bombarding" with SIGINTs I mean<br>
<br>
   while true; do kill -INT $pid; done<br>
<br>
python survives that test; sage doesn't. I think a lot of programs don't.<br>
<br>
By the way, I originally intended to send this whole thread to the ECL mailing list. Feel free to forward or summarize there if you think it is of general interest.<br>
<br>
Kind regards,<br><font color="#888888">
<br>
Nils Bruin<br>
</font></div><br><br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>