[cffi-devel] ECL specific changes for CFFI

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Thu Apr 29 07:49:03 UTC 2010


On Thu, Apr 29, 2010 at 1:02 AM, Luís Oliveira <luismbo at gmail.com> wrote:

> On Mon, Apr 26, 2010 at 1:51 PM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
> >> It is very problematic because ECL allocates and frees foreign memory
> >> using the garbage collector. If the user applies FOREIGN-FREE upon a
> >> pointer  that was NOT created using CFFI, then ECL's garbage collector
> will
> >> choke. The tests we causing ECL to hang.
>
> I see. What's the rationale? Could ECL's FOREIGN-FREE/ALLOC use plain
> malloc()/free()?
>

But why? As we said there is nothing in the CFFI specification that mandates
use of malloc(), just that the memory will not be freed
http://common-lisp.net/project/cffi/manual/html_node/foreign_002dalloc.html

Current system uses the same foreign memory manager as ECL, because it is
safer for us, allows a good coexistence of both sets of memory and allows us
to keep track of the amount of memory used. Furthermore, should it be
needed, some pointers can be allocated as collectable and automatically
reclaimed by our GC -- not that it is done by default, though --. This has
worked fine, it was the way UFFI worked, and I see no reason to change.

Also, except for OpenMCL I see no explicit use of malloc/free anywhere. It
must be some kind of accident that it works with other implementations.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20100429/57081333/attachment.html>


More information about the cffi-devel mailing list