<div class="gmail_quote">What about the code below? It has not been tested and might not be the optimal way, but it fixes various problems:</div><div class="gmail_quote"><br></div><div class="gmail_quote">* ecl_disable/enable_interrupts do not nest properly and thus can only be used around very small pieces of code, typically foreign C functions.</div>

<div class="gmail_quote">* for prolongued interrupts disabling, use the special variable ext:*interrupts-enabled*. This does not cause the use of mprotect() and just queues signals. It has to be matched by an interrupt check, which is what with-interrupts does.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">const cl_env_ptr env = ecl_process_env();</div><div class="gmail_quote">cl_object variable = ecl_read_from_cstring("sys::*interrupts-enabled*");</div>
<div class="gmail_quote">
<br></div><div class="im">/* Disable interrupts by lisp methods. All interrupts are queued. </div><div class="im"> * This is the preferred method to block interrupts for extended</div><div class="im"> * periods of time. */</div>

<div class="im">ecl_bds_bind(env, variable, Cnil);</div><div class="im"><br></div><div class="gmail_quote">/* Protect from unwanted transfers of control */</div><div class="gmail_quote">ECL_CATCH_ALL_BEGIN(env) {</div><div class="gmail_quote">

<div class="im">  set_our_sighandlers_to_postpone_signals();</div><div class="im"><br></div><div class="im">  sigaction(SIGINT,ecl_sigint_handler,NULL);</div>  sigaction(SIGSEGV,ecl_sigsegv_handler,NULL);</div><div class="gmail_quote">

<br></div><div class="gmail_quote">  result=ecl_eval("</div><div class="gmail_quote">     (handler-case</div><div class="gmail_quote">         (ext:with-interrupts <actual code here>) ;;interrupts happen here<br>

     <condition handling and reporting> ;;and caught and reported here<br>     )");</div><div class="gmail_quote"><br></div>  /* at this point there might be signals pending that<div>   * happened at the error condition and reporting part. </div>

<div>   * We probably should delete the following statement and</div><div>   * ignore those signals. */</div><div>  ecl_check_pending_interrupts();</div><div><br><div class="gmail_quote">} ECL_CATCH_ALL_END;</div><div class="gmail_quote">

<br></div><div class="gmail_quote">/* a signal arriving here would still be queued by ECL but won't<br>   be processed. */<br></div><div class="gmail_quote">sigaction(SIGINT,our_sigint_handler,NULL);<br>sigaction(SIGSEGV,our_sigsegv_handler,NULL);</div>

<div class="gmail_quote">/* ... hence we clear them */</div>ecl_clear_interrupts_env(env);<br><div class="gmail_quote"> </div><div class="gmail_quote">set_our_handlers_to_process_signals();<br></div><div class="gmail_quote">

<br></div><div class="gmail_quote">On Mon, Feb 28, 2011 at 8:12 AM, Nils Bruin <span dir="ltr"><<a href="mailto:nbruin@cecm.sfu.ca">nbruin@cecm.sfu.ca</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


Question: What would happen if a signal for ECL were queued but no<br>
mprotect were set? Would it take very long before the queue would be<br>
checked? Would the queue be checked at all?</blockquote><div><br></div><div>Not in general, unless the user code is wrapped in some without-interrupts, and then it would be checked only when exiting, or when there is some I/O going on.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If a foreign signal handler<br>
could get away with *just* queueing the signal to ECL, without<br>
mprotect-ing anything, integration would be much easier, because one<br>
doesn't have to deal with the possibility that a signal boomerangs back as<br>
a SIGSEGV (very elegant trick, though!)</blockquote><div><br></div><div>The problem with that is that it forces us to set up periodic interrupt checks that are costly, and should be scattered all over ECL's code. In general I believe it would be better to live without interrupts, in an even driven world plus some safe thread "aborting" operations.</div>

<div><br></div><div>Juanjo</div></div><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>


</div>