[Ecls-list] embedding ecl in multi-threaded C?

Ross Lonstein rlonstein+ecls at pobox.com
Tue Mar 10 14:14:04 UTC 2009


At Tue, 10 Mar 2009 09:51:37 +0100, Juan Jose Garcia-Ripoll wrote:
    [snip]
> First of all, I assume you only all cl_boot() once. I seemed to
> understand the opposite from your message.

Initially, no. That was my mistake. I tried various things including
using a library constructor routine to get it done early and check
ecl_get_option(ECL_OPT_BOOTED) to make sure it happens only once. The
constructor was unnecessary but there were problems in ecl_boot().
 
> Second, ECL's garbage collector only knows about the threads its
> creates. There are functions to import already created threads (void
> ecl_import_current_thread(cl_object name, cl_object bindings)) but
    [snip]

Yes. Found and applied this and ecl_release_current_thread() didn't get
to see if that mattered as ecl_boot() gets stuck with endless SIGSEGV's
when invoked in the callback from the vendor code. In my testbed it
works well :)

> Third, it seems that your vendor code unloads ECL after using the
> function? 

To clarify, it unloads it when a thread completes, not between multiple
invocations of the callback for a given thread. Other threads may still
have it loaded.

> Have you thought about writing a wrapper that loads your library and
> finds out the entry point every time it is needed. That wrapper
> should not be linked with ECL so that when it is unloaded, the
> library does not leave memory and continues to function.
    [snip]

This idea is interesting. When I have some time I will give it a try. I
was doing this during a short vacation and to keep momentum, I switched
to a minimal Scheme (tinyscheme) with a simple lifecycle and GC. After
learning from my attempts with ECL and Guile, I got it to play well with
the environment imposed by the vendor code but it is a bit spare.

- Ross




More information about the ecl-devel mailing list