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.
Am 08 Jan 2004 03:34:45 -0500 hat Jim Blandy <jimb@xxxxxxxxxx> geschrieben:
I don't understand this. If the C code does not hold direct references to the data (i.e. if you add an extra indirection), and if you access the data only over a designated interface, GC can certainly run whenever it wants, even during the execution of the C code. That's the whole point of the abstraction exercise.I'm sorry. I shouldn't be trying to write so late at night.
No worries.
In code using this SRFI's interface, there are two classes of Scheme values: - Values that reside in GCPRO'd variables. - Values that reside anywhere else: in other variables, compiler-generated temporaries, and so on. Values in the first class the GC can update when it relocates objects; those in the second class it cannot, because it can't find them. Values in the second class are unavoidable if you're actually operating on the values, since you can't control the code the compiler generates.
Absolutely. With the current SRFI-50 draft the problem is exactly as you point out.
By using the 'begin / end' pair of functions, you'd promise the SRFI-50 implementation that, outside such pairs, no values of the second class exist, and it is free to collect at any time. When any thread is within such a pair, there exist object references the collector can't find or update, so collection has to wait until the thread reaches a "may gc" function.
I should have been more precise there: I understand the intention behind the "critical section". My point is that with an extra-indirection (as proposed by Tom or as used in JNI/minor - if I understand it right) the second class values point to something opaque. The values insideC locals and registers point to some "box" object that could easily be registered
with the collector. Since the user can only access the data via extraction forms, it's completely transparent. This means that the problem would simply go away (IMHO), provided the current draft proposal is changed in an appropriate manner. cheers, felix