Some thread/GC questions
daniel at turtleware.eu
Wed Mar 9 13:15:06 UTC 2016
Juraj Variny writes:
> On Wednesday 09 March 2016 09:07:38 you wrote:
>> 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
Please also keep in mind this section of the manual (signal handling):
>> > 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?
>> > 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?
>> > Regards,
>> > Juraj
>> Best reagrds,
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
More information about the ecl-devel