[cffi-devel] [Fwd: RE: [Ecls-list] Foreign variables setting problem]

[Luis Oliveira]

On 24/out/2005, at 13:09, Juan Jose Garcia Ripoll wrote:
> I am forwarding you a question from one of our developers, who is
> working on updating CFFI to work with ECL.

I read that, it's great news.


> His question is how you handle garbage collection and foreign 
> variables.
> When setting these variables with, say, a copy of a string
>         (setf *var-string* "hello")
> a region of memory has to be allocated. But what happens when we set
> this variable again afterwards?
> 	(setf *var-string* "world")
>
> Does CFFI assume that foreign variables become part of the set of roots
> to be considered by the garbage collector? This seems a strong
> assumption, given the fact that not all variables will contain 
> pointers,
> etc.
>
> Or is the user expected to free the first string by herself?

Right now the user should free the first string (or whatever) by 
himself. I plan to add some options to DEFCVAR to make this automatic 
(something like what CLISP has). For example the setter that DEFCVAR 
defines would automatically free the previous contents of the foreign 
var.


> On the first SETF, CFFI will allocate a foreign string and set 
> *var-string*
> to point to it. The second SETF will do the same, without deallocating 
> the
> string "hello". To deallocate it, you would have to create a 
> foreign-data
> object pointing to the same address as *var-string* and then free it, 
> this
> looks tricky....

Well it is a bit tricky to free because you have to dodge the 
translator... but not *that* tricky.

(setf *fvar* "foo")
(foreign-free (mem-ref (get-var-ptr '*fvar*) :pointer))
(setf *fvar* "new string")

Any suggestions on how to handle this better? Or is the automatic 
solution I mention before (regarding the setter) enough?

Btw, the test case Michael is talking about 
(foreign-globals.set.string) does indeed leak memory, I've fixed that.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt