Some thread/GC questions

Juraj Variny rini17 at gmail.com
Wed Mar 9 12:51:20 UTC 2016


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. 

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

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




More information about the ecl-devel mailing list