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?
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?
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
Hello,
Juraj Variny writes:
Hello,
can you please tell me how to:
- 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.
- 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.
- 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.
- 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
On Wednesday 09 March 2016 09:07:38 you wrote:
Hello,
Juraj Variny writes:
Hello,
can you please tell me how to:
- 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.
- 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.
- 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.
- 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
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:
- 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
- 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.
- 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.
- 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 -
Juraj Variny