allocating memory for c-structures

allocating memory for c-structures

[micha]

Normaly I allocate memory for c-structures with malloc or with "new" for 
c++ objects. Some time ago a read about a library which places external 
structures in strings of the interfacing languages (it was a scheme lib 
I think). So instead of using malloc or new I would allocate an 
ocaml-string and put the c-structure there. So it will be free by the gc.
That seems o.k. for me, any comments? I'm missing something?

cheers
 Michael

Re: [Caml-list] allocating memory for c-structures

[skaller]

On Tue, 2006-12-26 at 19:15 +0100, micha wrote:
> Normaly I allocate memory for c-structures with malloc or with "new" for 
> c++ objects. Some time ago a read about a library which places external 
> structures in strings of the interfacing languages (it was a scheme lib 
> I think). So instead of using malloc or new I would allocate an 
> ocaml-string and put the c-structure there. So it will be free by the gc.
> That seems o.k. for me, any comments? I'm missing something?

I don't believe Ocaml guarantees the contents of a string
will remain in a fixed location .. it might move the storage
to a new address .. so pointers into the structure might
dangle.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] allocating memory for c-structures

[Richard Jones]

On Tue, Dec 26, 2006 at 07:15:35PM +0100, micha wrote:
> Normaly I allocate memory for c-structures with malloc or with "new" for 
> c++ objects. Some time ago a read about a library which places external 
> structures in strings of the interfacing languages (it was a scheme lib 
> I think). So instead of using malloc or new I would allocate an 
> ocaml-string and put the c-structure there. So it will be free by the gc.
> That seems o.k. for me, any comments? I'm missing something?

That seems like it'll work for "opaque" C objects, but it's a bit of a
hack.  The immediate issues I can think are:

(a) Pointers in the C code which point at the object will not be
"counted" by the GC, and so the object may be collected while there
are still C pointers around.  This is easily avoided in OCaml, but
read chapter 18 of the manual carefully.

(b) By storing the object as a string you're telling the GC not to
examine the inside of the object, eg. looking for pointers inside to
other objects.  Fine, if you know what you're doing, but OCaml already
has a number of established ways to do this - eg. using Abstract or
Custom blocks - and these standard ways are not just standard, but
offer additional features too.  Alternatively you may consider a
non-abstract block and deliberately allow the GC to look inside.  C
and OCaml structures are not actually too different.

Actually, while I was writing the above, it struck me that perhaps
you're talking about some sort of marshalling system?  OCaml supports
its own marshalling format, and a rich variety of other external forms
of marshalling.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] allocating memory for c-structures

[micha]

thanks for all the answers.

Richard Jones schrieb:
>
> That seems like it'll work for "opaque" C objects, but it's a bit of a
> hack.  The immediate issues I can think are:
>
> (a) Pointers in the C code which point at the object will not be
> "counted" by the GC, and so the object may be collected while there
> are still C pointers around.  This is easily avoided in OCaml, but
> read chapter 18 of the manual carefully.
>   
that's true; for linked data structures it would not work (except all
would be allocated this way)


> Actually, while I was writing the above, it struck me that perhaps
> you're talking about some sort of marshalling system?  OCaml supports
> its own marshalling format, and a rich variety of other external forms
> of marshalling.
ah no, I just thought that it would be another way to handle external
memory.
What I didn't realize was, that the gc moves pointers around...

cheers
Michael