GC and Threading

[Bixbox]

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 at turtleware.eu>
Inviato: ‎25.‎10.‎2015 13:05
A: "Bix" <strabixbox at yahoo.com>
Cc: "ecl-devel at common-lisp.net" <ecl-devel at common-lisp.net>
Oggetto: Re: GC and Threading

Hello,

Bix writes:

> Hi,
> 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?

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.

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

-- 
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel

"Be the change that you wish to see in the world." - Mahatma Gandhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20151104/16a5110d/attachment.html>