GC and Threading

[Matthew Mondor]

On Sun, 25 Oct 2015 09:28:03 +0100
Bix <strabixbox at yahoo.com> wrote:

> just two quick question:
> 1. Is it possible to disable the threading model and have multiple
> thread to eval the code or have one ECL per thread?
> 2. Can the garbage collector be disabled at all and have the memory
> managed in a reference counting fashion?
> 
> I like to embed the ECL in my multithread application but I've got
> very restrictive constrain about thread and memory:
> * I can not spawn new thread but I've got concurrent thread to execute
> ecl call.
> * A component that bring GC would probably not be accepted and I'm
> wondering if there is an alternative to that in ECL, or at least have
> more control how/when GC will be run.
> 
> 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...

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).

It's also possible that your application might itself benefit from the
GC; the library also remains friendly to code using explicit freeing.

-- 
Matt