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] |
Dale Jordan <dalej@alum.mit.edu> writes: > The documentation on smobs indicates that a new instance is allocated > by scm_must_malloc, after which the C program must build a cell with > the correct type tag and a pointer to the malloc-ed memory. There is > no mention whether an alternate means is allowed. Unfortunately, > scm_must_malloc is used all over Guile itself, so we couldn't use it > directly to find smobs. There wouldn't seem to be any restriction on > using it for other purposes, either. I was thinking more along the lines of having a general allocation like scm_must_malloc that would be used by smob programmers as necessary (scm_must_malloc just counts bytes to figure out how much memory has been malloc'd for triggering gc's). > We could try the value-added approach and provide a function defined as > > SCM *scm_make_instance(long smob_tag, scm_sizet smob_size) > > that did the allocations and returned the cell pointer already set > up. This would let us control where the memory was allocated from. > It would have to become the only supported way to allocate a smob > instance. This isn't really flexible enough for smobs... I would expect that most won't consist of all scheme values (or areas of memory that can contain scheme values) so it would be a waste on traps to those regions of memory. I think it's better to put that into the hands of the programmers. This still begs the question of what to do if someone mallocs a chunk of memory, then memcopy's an smob over, but the most sensible answer is "don't do that" ;) Another thing that will be needed is a smob relocation function (basically, just something where we can do smob_relocate(SCM old_cell, SCM new_cell) for smobs that can contain pointers to themselves that aren't in the heap). > I haven't looked at many smobs, but the few I've defined have not kept > pointers to scheme objects. It might be helpful if the smob > description provided that information. If they don't hold pointers > they don't have to be traced except when their header cell is collected. > In this case, they can just use the current functions. What is needed is something like scm_alloc_protected(scm_sizet foo). Even better would be to allow the smobs to tell us where the scheme pointers can be, to save on scanning, but it shouldn't be absolutely necessary. -- Greg