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