Some thread/GC questions

[Daniel Kochmański]

Juraj Variny writes:

> On Wednesday 09 March 2016 09:07:38 you wrote:
>> Hello,
>> 
>> Juraj Variny writes:
>> > Hello,
>> > 
>> > can you please tell me how to:
>> > 
>> > 1. Initialize lisp environment in a thread that was already created by
>> > C/C++ app? Is it possible for it to share existing lisp environment?
>> 
>> There is an example in examples/embed directory (file hello.c). What do
>> you mean by sharing an existing lisp environment? cl_boot creates an
>> environment for this instance.
>
> Say I have main thread, where cl_boot was called, with some lisp environment. 
> Then I call cl_boot in some other pre-existing thread, would it be able to 
> access lisp environment of the main thread, evaluate symbols defined there, 
> call functions etc? This is what I meant with shared environment.

It is enought to call cl_boot once. Calling it a second time won't do
any harm, but the cl_boot isn't thread-safe, so don't call it twice at
the same time from different threads.

After calling cl_boot once you should be able to work with lisp from any
thread.

Please also keep in mind this section of the manual (signal handling):
https://common-lisp.net/project/ecl/manual/ch32s04.html
>
>> > 2. Is accessing and modification of the shared lisp environment from a new
>> > thread made by (mp:process-run-function) threadsafe? For example I am
>> > running swank this way, is this a safe practice?
>> 
>> It is meant to be. Any reproducible bug should be reported here:
>> https://gitlab.com/embeddable-common-lisp/ecl/issues/ . I'm using swank
>> from the separate thread in ecl-android and I didn't encounter problems
>> with that.
>> 
>> ECL's swank backend contains in comment some hint regarding the thread
>> safety (not sure though, how up-to-date it is):
>> 
>>   ;; While ECL does provide threads, some parts of it are not
>>   ;; thread-safe (2010-02-23), including the compiler and CLOS.
>> 
>> it is something I want to investigate. I'm currently working on
>> something else in the compiler though.
>
> I do see corruption in this scenario. But it is so far anectotal or may be my 
> own error (failed to prevent 3. and 4.), will make an issue if I reliably 
> reproduce it.

Thanks.
>
>> > 3. In the environment where only ECL is garbage collected: Calling
>> > ecl_base_string_pointer_safe(si_copy_to_simple_base_string(obj)) means
>> > that
>> > resulting C string will be eventually garbage collected?
>> 
>> Yes.
>> 
>> > 4. Likewise (ffi:c-inline () () :cstring "...") returns the value via
>> > ecl_cstring_to_base_string_or_nil() which causes trouble when C side
>> > deallocates it, I presume?
>> 
>> Yes.
>> 
>> > Regards,
>> > 
>> > Juraj
>> 
>> Best reagrds,
>> Daniel


-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański      | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi