On Sun, 25 Oct 2015 09:28:03 +0100 Bix strabixbox@yahoo.com wrote:
just two quick question:
- 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.