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

[Peter Enerccio]

Here is my simple REPL like code. It is evaluated by this function:

void eval_in_new_thread_mt(char* buffer){
    cl_object cl_buffer = c_string_to_object(buffer);
    thread_t* thread = create_thread(eval_nt, cl_buffer);
    cl_object ret = (cl_object) thread_join(thread);
    printf(": ");
    cl_print(1, ret);
    printf("\n\n");
}

Now, everything works fine, as long as there is no problem. But when
problem, such as when evaluating (+ 1 'a), it will crash with sigsegv:

Debugger received error of type: SIMPLE-ERROR
Attempted to recursively lock #<lock (nonrecursive) "Console lock"> which
is already owned by #<process 0000000002f3a000>
Error flushed.

which repeats a lot.


2012/11/2 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>

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



-- 
Bc. Peter Vaňušanik
http://www.bishojo.tk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121103/3eee8e31/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repl.c
Type: text/x-csrc
Size: 939 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121103/3eee8e31/attachment.c>