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
