GC and Threading
strabixbox at yahoo.com
Thu Nov 5 22:39:20 UTC 2015
Matthew Mondor writes:
> On Sun, 25 Oct 2015 09:28:03 +0100
> Bix <strabixbox at yahoo.com> wrote:
>> just two quick question:
>> Can you point me out where to look in the source code to understand
>> those aspect of ECL?
> If your OS supports real processes, you could fork() some processes
> dedicated for ECL, such that ECL's heap and gc wouldn't interfere with
> your application. Alternatively, you could use separate ECL-based
> server daemons to which your application would connect. ECL could then
> also either work non-threaded or threaded in that, or those processes,
> depending on your needs.
> However, you'd also then have to invoke ECL in an RPC manner from the
> main application. An example is emacs+SLIME connecting to ECL+swank,
> which uses a simple s-exp based exchange protocol. Other examples
> would be using JSON messages, SOAP/XMLRPC, HTTP/REST, FastCGI, CORBA,
> etc, and of course you could implement your own text or binary
> communication/memory-sharing protocol, using the most appropriate IPC
> method for your use-case...
I'm thinking about that possibilities but I really like to embed the
engine in the very same engine to share the structures.
> On the other hand, if you need ECL to have direct access to objects
> within your application's heap, you'd currently have no choice, your
> application would indeed dynamically link boehm-gc, and any thread
> calling into ECL would have to be "registered" with ECL (threads
> started by ECL itself are automatically registered).
I'm exploring that interesting possibility. I don't like that the GC
halt all the other thread but only the ones involved in the
embedding and calling of ECL. So I studying if it possible to register and
de-register a thread.
Given that my threads does not share anything I hope that I can have the
thread de-register himself when the ecl part is no more needed so
everything created by that thread can be collected.
1. Register my thread
2. Execute some lisp on ecl
3. Collect/copy he results
> It's also possible that your application might itself benefit from the
> GC; the library also remains friendly to code using explicit freeing.
More information about the ecl-devel