This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Russ McManus <russell.mcmanus@gs.com> writes: > > There are currently too many places where you have to have a > > somewhat intimate knowledge of the inner workings of Guile to get > > things right (and the lack of documentation doesn't help a bit). > > Other than initializing a smob, can you think of others? I'd like > to document the ugly spots, and known work arounds. > There are two that pop to mind right now: The phantom pointers thing (not Guile's fault, but there should be some mention of it), where you fetch a pointer to a chunk of data out of a SCM value and don't use the SCM value again, leading to the compiler optimizing out the scheme value, and a gc collecting it. You can get around this using scm_remember(&obj) or scm_return_first(retval, obj, ...) in the function. Using scm_must_malloc for storage that can't be reclaimed by the garbage collector (this mistake happens in the guile code, as well... it's not necessarily critical, but it's also not a good thing for the gc to think it's got to handle more memory than it does). This should really be handled by guile providing a few additional functions (I've added scm_nonobj_foo, which checks return values and might signal a gc, but doesn't add this to the total the gc thinks it's keeping track of). -- Greg H