[Ecls-list] Repl loop running in another thread and non blocking?

[Juan Jose Garcia-Ripoll]

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

On Fri, Nov 2, 2012 at 3:46 PM, Peter Enerccio <enerccio at gmail.com> wrote:

> 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.
>

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

* Your own threads
* A secondary thread that waits for signal. This thread can be deactivated
using ecl_set_option() http://ecls.sourceforge.net/new-manual/re93.html

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.

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)

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

* Change the signal handler
* Block the associated signals
* Deactivate the thread entirely but this will cause trouble.

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.

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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121102/342eac31/attachment.html>