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.
> From: Richard Kelsey <kelsey@xxxxxxx> >> [....] > [....] All that is required is that the incremental GC scan the > entire root set in a single increment before deciding that it > has reached the end of a [trace] cycle. This is standard practice > for incremental GCs. That's true only if the root set is small enough that it doesn't exceed the amount work the tracer will want to do in one step. What may be a common practice is to write implementations in such a way that the root set is guaranteed to be small -- but that's not the same thing as what you've said and the difference matters. If the root set is large, certainly it should be traced in several steps, using barriers to preserve its invariants. Absent any further guidance from the FFI spec, I would expect some programs to register a very large number of locations -- and worse, locations scattered widely in memory -- using SCHEME_GC_PROTECT_GLOBAL. (Why wouldn't I, in a printed circuit board CAD program, GCPROtect a field of every C structure representing an edge in a netlist graph?) And while the C stack (and hence the number of locations protected by SCHEME_GC_PROTECT) will _usually_ be small and localized, there is nothing to preclude it being rather large. In short, the FFI requires a root set of unbounded size and unrestricted locality: the common practice of tracing roots in a single step does not apply here. The problem goes away if the FFI imposes barriers over GCPROtected values. Alternatively, perhaps SCHEME_GC_PROTECT_GLOBAL should simply be removed from the FFI. Programs can instead use integer indexes into some data structure allocated in the Scheme heap, conceptually allocating and freeing integer addresses to make them coextensive with the C heap locations they would otherwise pass to SCHEME_GC_PROTECT_GLOBAL. The stack would remain an annoyance but, I admit, a less fatal one. > SCHEME_CAR() and SCHEME_SET_CAR() and so forth need to preserve > any read or write barriers, of course. Sure, and that's good. > (You also talk about threads and interruption points related to them > but, of course, that doesn't address truly concurrent threads.) > I am not sure what 'truly concurrent' means (parallel execution?). > But yes, we chose efficient C execution over allowing the C code > to be interrupted at arbitrary points. Yes that's what I mean. But in a later message you remark that you prefer the current FFI over Pika _not_ for efficiency reasons but for aesthetic reasons. I'll take that issue up in reply to the later message but let's here note that you want to make the FFI incompatible with some kinds of threading (for which hw support is increasingly popular and cheap) for reasons of syntax, not efficiency. And, threads aside, there's the issue of asyncronous execution from signal handlers. While it's just fine to postpone to a later SRFI giving FFI-using code hooks into async mechanisms, what you have in this FFI is an interface that rather severely restricts implementations that use async execution internally. And again, the justification we're down to for that restriction is, apparently, concern over syntax. -t