[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I don't believe in "(may GC)"
> From: Richard Kelsey <kelsey@xxxxxxx>
> Date: Sun, 4 Jan 2004 17:21:41 -0800 (PST)
> From: Tom Lord <lord@xxxxxxx>
> The draft FFI says:
> double SCHEME_EXTRACT_DOUBLE(scheme_value)
> char * SCHEME_EXTRACT_STRING(scheme_value)
> Neither says "(may GC)".
> If I'm using some exotic number representation (constructive reals,
> perhaps), then EXTRACT_DOUBLE may very well involve some pretty hairy,
> hence possibly GC-causing, computation.
> This doesn't worry me too much; there aren't a lot of such
> implementations around.
How about implementations that implicitly force promises?
> If I'm using some exotic string representations (I'm working on a
> functional-splay-tree string type for Pika) -- same deal:
> extract-string may take some (possibly GC-causing) work.
> This does worry me (it's listed in the 'issues' section of the SRFI).
> I think we went overboard here. Something like
> SCHEME_EXTRACT_STRING_CONTENTS(scheme_value, index, count, buffer)
> which copies 'count' characters starting from 'index' into 'buffer'
> would be better. Presumably this can be done without GCing.
In the case of a splay string, sure. In the case of a lazilly
instantiated string, not so obviously. (Mobile code, perhaps?)
> Even something innocent like:
> int SCHEME_CHAR_P(scheme_value)
> can cause GC if my implementation let's me attach to a hook in its
> Again, I don't think this will be very common. Is there an
> existing implementation for which this (or anything similar) is
> an issue?
That supports hooks in arbitrary Scheme primitives? I presume so.
But you've lost me on why "not common" or "no implementation does that
[quite reasonable thing] yet" arguments are relevent to this FFI.
Regarded as a social engineering hack, I presume that the reason to
make this an FFI is to (a) lead to lots of libraries being given
FFI-using wrappers; (b) lead to lots of implementations supporting
the FFI. Great goals -- but there's no reason to gratuitously
force all present and future implementations to emulate the GC
idiosyncrasies of S48.