Re: Passing C pointers through guile

[Kjetil S. Matheussen]

Ludovic Court?s:
>> I gave it a try. Unfortunately, I was completely unable to create
>> the configure file right now, so the patch is against 1.8.5 (sorry
>> if this creats trouble against git repository), and
>> it's also untested, since I couldn't build configure.
>
>You have to make sure you are on the `branch_release-1-8', and then
>"autoreconf -vfi" should suffice to produce everything.  Autoconf 2.61,
>Automake 1.10 and Libtool 1.5.26 is all you need.

Thanks. It would be nice if that information was in the source 
too...


> > The only thing I'm not too sure about is whether
> > the new SCM_I_GSC_T_UINTPTR type in configure.in will actually be
> > optional or not. I just copied the checking code for the optional
> > SCM_I_GSC_T_UINT64 type though:
>
> I think this type shouldn't be optional, because there will always be a
> pointer-sized integer type (whereas there could be platform without
> 64-bit integers).

But isn't the only way to make sure that an integer size
is big enough to hold a pointer, to use uintptr_t from
stdint.h ?

It does get a little bit complicated if Guile is compiled 
on a platform without stdint.h


>>> That said, using a Scheme integer to represent a pointer wouldn't be
>>> efficient (pointers would likely translate to bignums).
>>
>> I think cleaner code would usually be more important in this case,
>> but at least there will be a choice.
>
>I'm not sure how much cleaner this is.  Usually, you'll want disjoint
>Scheme types, which means you'll end up enclosing the pointer-as-bignum
>in a structure or SRFI-9 record or similar.  This leads to even more
>overhead.  Conversely, using an opaque field in a Guile struct has the
>same effect but with much less overhead.

It's cleaner because it requires a magnitude less code.

>Another issue is that of memory management.  When using
>pointers-as-bignums, all the GC will see is a collection of bignums, not
>knowing that these are actually pointers to C objects that should not be
>GC'd unless the integer is no longer used---as opposed to "no longer
>referenced"!  This actually makes it mandatory to enclose the integer in
>a structure or similar, and then to have a guardian on that structure to
>allow the C object's destructor to be called when that structure is no
>longer referenced.

That's true. But at least my experience is that using guardians
is cleaner than smurf's. For example, I think the use of guardians for 
faust objects in http://snd.cvs.sourceforge.net/snd/cvs-snd/rt-faust.scm
is very simple, it's just one line: "(add-finalizer (-> faust 
get-c-object) cleanup-faust-object)".

Also, various types of non-gc pointers are stored in integers in
all of the rt-*.scm files in http://snd.cvs.sourceforge.net/snd/cvs-snd/
and many others (xg.c, etc.). It would be horribly idiotic
to write smurf's for all of those, or at least a common smurf, when a 
single integer is enough.




>PS: You'll have to assign copyright to the FSF so that your code can be
>    integrated.  We can discuss it off-line if you want.

Okay, just tell me what to do.