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.
Date: Wed, 31 Dec 2003 13:59:09 -0800 (PST) From: Tom Lord <lord@xxxxxxx> rk> I can't imagine why an implementation would allocate any of rk> these constants on the fly. tb just gave you one. No, (a) he gave a reason why you might have multiple C values representing Scheme's #F. He didn't give a reason why you would allocate those values on the fly (as opposed to creating them when the corresponding heap is created). And (b), my point is not that there are no advantages for doing so, but that any benefit from it would be outweighed by associated costs. So, basically, you don't care about threads or async execution? It's only if you don't care about those things that you need to indicate which functions may trigger GC. Otherwise, GC may occur anytime that it isn't specifically excluded. Absolutely correct. Within the context of this SRFI I don't care about asynchronous execution (I do care about threads, but as long as C code is not interrupted asychronously they don't matter). The GC protection mechanism described in the SRFI is inadequate if GCs can occur asynchronously. Even if variables 'a' and 'b' are protected, there is no guarentee that a = b; will not temporarily store the value of 'b' in some unprotected location such as a register. > I can't see declaring that SCHEME_FALSE, SCHEME_TRUE, > SCHEME_NULL or SCHEME_UNDEFINED might trigger a GC just because > there might someday exist such an implementation. You haven't given any _positive_ reasons for making exceptions of those values. We aren't making exceptions of those values. We carefully tried to minimize the number of GC-triggering operations. Why would it be more regular to label them as possibly causing a GC? It would be more regular to label everything as possibly causing a GC, but that would make writing C code that used the FFI too painful. -Richard