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

Fri Nov 9 20:54:01 UTC 2012

The problem is that your code was wrong. It passed wrong arguments to a
function and thus it triggered an infinite chain of SIGSEGV. The right code
would be the attached one.

Note that cl_safe_eval() does not invoke the debugger and all forms that
fail are simply ignored. Thus, no thread using such code for evaluation
would lead to instabilities, were it not for other code that you write
outside that form and which is definitely wrong.

Juanjo

On Sat, Nov 3, 2012 at 12:38 AM, Peter Enerccio <enerccio at gmail.com> wrote:

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

-- 
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/20121109/90b46609/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 142 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121109/90b46609/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_fixed.c
Type: text/x-csrc
Size: 1310 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121109/90b46609/attachment.c>