This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
On Sun, 18 Jan 2004, Tom Lord wrote: > > > > From: bear <bear@xxxxxxxxx> > > > > I think "may GC" applies to all entry points. > > > I tend to agree, but this means no live C pointers directly at > > storage occupied by scheme data. > > You mean such as a C `char *' pointing directly at, say, some string > data? That's certainly one example. > If so, no -- that's not what it (necessarily) means. That's a topic > we haven't taken up much and is slightly tricky, imo. Options to > consider are the ability for C code to dynamically declare > GC-excluding regions (within which at most a subset of the FFI is > available) and the ability to dynamically declare regions during which > certain objects are "locked" (with, again, limits on what part of the > FFI is available). Oy. what you seem to be saying, is that if it doesn't imply that, then it implies heroic measures of ever-escalating hair. A copying Garbage Collector can move something. Is the C code expected to know it's been moved? Or is the act of getting a pointer to "shared" data supposed to notify the Garbage Collector to not move that particular object? Also, there are possibilities like copy-on-write semantics inside the scheme systems, where >1 variables may share storage until one of the copies is written to, at which point it gets a new address. An FFI that tries to write things by using a live pointer into scheme storage is not going to have the right effect here if it doesn't execute the hooks that copy-on-write depends on on the scheme side. An FFI that's unaware of the fact that the copy it thought it had a pointer to got moved to a new address when written from the scheme side is going to mess up subsequent reads. >> I would say that this is an excellent summary. Barrierless >> read/write (C) is probably the biggest problem here as far >> as I'm concerned. I could live with sequence-point GC (A). > I think that, in general, A alone is the least controversial. But > another way to view the design space is that if you want an FFI that > doesn't imply "C", then the seemingly natural choices for that FFI > also don't imply "A" and aren't consistent with "B". > In other words -- once you say no to "C", there's no good reason not > to say no to "A" and "B" too. The strucutre sharing issues _might_ > give a reason to say yes to "A" without implying "B" or "C" -- but > they shouldn't be exposed in a portable FFI. I'm pretty much of the opinion that what gets passed back and forth across the FFI should be values, not pointers. Let the C code ask what the value of X is when it wants it, or pass a value back to store in X. It solves all of these problems, I think, by making it not-matter when GC happens, keeping C code out of the structure of the scheme heap, and making it impossible to run into what-does-it-mean problems with shared structure. Bear