Memory management and type casting in XS

[Ye Wenbin]

Hi,
I am going to write a XS binding for an C library. I have some
question about the memory management and type casting. For example,
the library contain a string and list module. I bind DESTROY to
str_del function which free the string struct, that is ok when using
the string module alone. But if with list, there comes the problem. If
I use list_get to fetch a element from the list which is a string and
the result is a perl object in a scalar. When the object go out of the
scope, it will invoke DESTROY function. But the list still has the
pointer to the string. Because the string module don't have reference
count, so it is not posible to decide whether free the object or not
in DESTROY function. So how to deal with this situation?

I try two method which seem can work but not very good.
First is add a flag in perl string object which tell DESTROY to
release the memory or not. Second one is making the list_get function
return a copy of the string. Both are not generic solution for all C
struct and may introduce bugs in using the object.

Another question is how to convert data in list. The element in the
list is a void* pointer. There should be a convertor to make the
pointer understand to perl. What I plan to do is add an attribute
"type" to the list object which is the package name for the pointer.
So output from C code can use sv_setref_pv to make the pointer blessed
to the package, input from the perl is the IV value of the object
reference which can convert to a pointer. Is there other way to
do that?

Thanks for advice!

Regards,
Ye Wenbin

 

[Anno Siegel]

Hi,
I am going to write a XS binding for an C library. I have some
question about the memory management and type casting. For example,
the library contain a string and list module. I bind DESTROY to
str_del function which free the string struct, that is ok when using
the string module alone. But if with list, there comes the problem. If
I use list_get to fetch a element from the list which is a string and
the result is a perl object in a scalar. When the object go out of the
scope, it will invoke DESTROY function. But the list still has the
pointer to the string. Because the string module don't have reference
count, so it is not posible to decide whether free the object or not
in DESTROY function. So how to deal with this situation?

Make copies that can be dealt with by perl's garbage collection.
In general that's the only safe way to return data from an external
library to perl space.

[...]

Anno