<div class="gmail_extra">I am fwd this to the mailing list because I do not want to repeat these answers or restart this discussion for every user that might find such problems. This is what the mailing list archives are fore</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">On Fri, Nov 2, 2012 at 3:46 PM, Peter Enerccio <span dir="ltr"><<a href="mailto:enerccio@gmail.com" target="_blank">enerccio@gmail.com</a>></span> wrote:<br>

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":aj">Well, I can get my own stdin thread in it, but it has the problem that once there is error, it will go crazy about console resource being already acquired, all over.</div>

</blockquote></div><div><br></div><div>I think you are mixing things and I do not manage to make myself understood. When ECL is embedded it does not launch a toplevel and there is no thread that grabs the console from start. What you will see is</div>

<div><br></div><div>* Your own threads</div><div>* A secondary thread that waits for signal. This thread can be deactivated using ecl_set_option() <a href="http://ecls.sourceforge.net/new-manual/re93.html">http://ecls.sourceforge.net/new-manual/re93.html</a></div>

<div><br></div><div>Console is and should be at this point free for any thread to use. No thread will be using stdin at this point and I do not understand why you mention this about resource being acquired.</div><div><br>

</div><div>Continuing with the explanation, whenever an error happens, Common Lisp mandates that a default error handler exists. By default this handler will invoke the debugger and it is those debuggers which will grab the console. You can prevent this from happening using standard tools, which range from intercepting the debugger, to setting your own handlers. But in theory, if errors only happen in one thread it should be ok. Even nested errors are ok if they do not totally prevent the debugger from running (i.e. stack overflows may do so, memory exhaustion is a hardly correctable error)</div>

<div><br></div><div>You say that that thread is grabbing the console and this can only be happening because your program is generating interrupts, such as Ctrl-C or SIGSEGV, or some other events. In this case the secondary thread spawns an error handler for each signal, which is standard practice. You may</div>

<div><br></div><div>* Change the signal handler</div><div>* Block the associated signals</div><div>* Deactivate the thread entirely but this will cause trouble.</div><div><br></div><div>A more troublesome situation is when there are multiple signals coming from all threads and they saturate the debugger, but hey, here there is _nothing_ sensible that the implementation can do.</div>

<div><br></div><div>So, summing up, if there is no debugger already running because some thread was there, your application should be ok with having the current distribution of threads. Otherwise I must ask you to provide a minimally reproducible test case to solve your problems. Without a more precise description I cannot do anything -- you already saw that with the outdated ECL stuff.</div>

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