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.
Felix Winkelmann <felix@xxxxxxxxxxxxx> writes: > > What he wrote seems clear enough. If SRFI-50 provided a begin/end > > pair of functions that indicated that the calling thread was holding > > no references to heap objects, then collection wouldn't need to wait > > for threads in that state. One could call the 'begin' function when > > beginning use of SRFI-50 functions, and the 'end' function when > > leaving the module. > > > > 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. 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. 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. Is that better? Or worse? :)