Matthew Mondor writes:
On Sun, 25 Oct 2015 09:28:03 +0100 Bix strabixbox@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.
Kind of: 1. Register my thread 2. Execute some lisp on ecl 3. Collect/copy he results 4. De-register
It's also possible that your application might itself benefit from the GC; the library also remains friendly to code using explicit freeing.
Kindest Regards bix