Thanks for the info. Having a single thread that manage the request may be an option. I have some concern that it would not keep up with a high volume of requests.
Cheers Bix
----- Messaggio originale ----- Da: "Daniel Kochmański" daniel@turtleware.eu Inviato: 25.10.2015 13:05 A: "Bix" strabixbox@yahoo.com Cc: "ecl-devel@common-lisp.net" ecl-devel@common-lisp.net Oggetto: Re: GC and Threading
Hello,
Bix writes:
Hi, 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?
You can build ECL without the threading support. You have to pass "--enable-threads=no" to the configure script. You can eval the code from the different threads but it's unsafe (concurrency).
Best solution would be to create a dedicated thread which will manage ECL calls.
You can't run separate ECL images from the same application AFAIK. It is a nice feature proposal though.
- Can the garbage collector be disabled at all and have the memory
managed in a reference counting fashion?
GC manages only the objects created by ECL. The collector won't scan the data sectors and you have to notify it if you want your data to be collectable.
GC may be disabled by calling the function `GC_disable()'. Explicit call to the GC
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.
As above: compile ECL without the threads support and manage it from the separate thread. Is that what you want?
- 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.
ECL uses Boehm-Demers-Weiser Garbage Collector. More information about it might be found here: http://www.hboehm.info/gc/ .
Can you point me out where to look in the source code to understand those aspect of ECL?
Of course. Keep in mind though that it's inherited codebase and my information might be inaccurate (sorry about that).
src/c/alloc.d - obsolete in-house GC which doesn't work src/c/alloc_2.d - necessary bridging between bdwgc and ECL. `si_gc' runs calls the GC explicitly in a safe manner src/c/main.d - `cl_boot' function starts the lisp, ecl_option_values contains configurable options src/c/unixint.d - handling the signals. Documentation available here: https://common-lisp.net/project/ecl/manual/ch32.html
There is some documentation about GC here: https://common-lisp.net/project/ecl/manual/ch30.html#ext.memory.intro but it's rather scarce. Also a very important note on handling signals: https://common-lisp.net/project/ecl/manual/ch32s04.html
Thanks in advance. f.
Best regards, Daniel