Hi,
Vladimir Tzankov is the thread expert of CLISP's experimental
thread branch, and here's what he has to say on this topic:
On Tue, Jul 30, 2013 at 4:33 PM, Felix Filozov <ffilo...@gmail.com> wrote:
> When defining a foreign function using def-foreign-call, there's an
> option one could set called :allow-gc. Setting it to :always, allows
> the garbage collector to run while the foreign function is executing.
>
> At the moment CFFI uses the default value for :allow-gc, which is :never.
> This prevents GC from running when a foreign function is executing.
>
> Moreover, once GC blocks, other processes can't make progress. In my
> case, I need GC to run during foreign function execution.
Stelian Ionescu wrote:
> SBCL never disables GC globally, and I don't think that CCL, ECL or
> ABCL do that either.
> [LispWorks] has no mention of GC, so it would seem that among SMP Lisps
> Allegro
> is the only one to do sophisticated stuff. CMUCL and Clisp are currently
> single-threaded so GC is implicitly disabled during foreign calls.
Luís Oliveira wrote:
>If we can confirm that ACL is the outlier, then (a) I'm all for changing
>cffi-allegro's
>implementation to match the semantics of the other Lisps and (b) documenting
>these semantics in the manual.
Vladimir Tzankow wrote (posted with permission):
>While there is no official CLISP release with threads support - threads are
>usable
>when built with --with-threads configure option.
>GC is stop-the-world one i.e. all threads are suspended at safe points
>while one of them is performing the GC. FFI calls are safe points as well
>which means that if a thread is in FFI call (blocked or whatever)
>the GC is allowed to run. The only complication is when a pointer
>to object in the heap has been passed to foreign code. In this case we
>"pin" the object before leaving lisp land. GC knows about pinned objects
>and do not move them around.
>Pinning is used mostly for i/o (streams.d) where we pass pointers
>in heap to syscalls (read,write,etc).
>There is no Lisp interface to pin objects. Code called via FFI never
>gets direct pointer in the heap.
>Nevertheless GC is allowed while the control is in foreign call.
These days, it feels backward IMHO to disable GC by default.
Regards,
Jörg Höhle
