On Wed, 14 Jul 1999, you wrote: >Hi, > >In message "[ruby-talk:00490] Some questions concerning GC in Ruby extensions" > on 99/07/14, Clemens Hintze <c.hintze / gmx.net> writes: [...] >ALLOC_N() is just a wrapper for xmalloc(). Unlike Bohem's >conservative GC, Our true GC treats objects only. All the memory >referred from objects are allocated by malloc(); deallocated by free >function called from GC. I have assumed, you use the Bohem's GC. Why not? Does the GC only collect data, which are some kind of Ruby object? What would happen with the memory allocated for `buf' in the following useless example? char *buf; while (<some condition>) { buf = ALLOC_N(char, 12); strcpy(buf, "hello"); gc_start(); } Here the pointer `buf' will be overwritten many times. I have assumed, that there would not be any memory leak, as we have true GC. But now, after reading your explainations and after short studying of `gc.c', I fear, that it leaks the more memory, the more I repeat the loop! Please tell me, that I am wrong! :-| Furthermore, If I do something like this: #define TESTSTR "Help" struct string { char *buf int size } int length = strlen(TESTSTR); VALUE str; struct string *strp; str = Data_Make_Struct(klass, struct string, 0, free, strp); strp->buf = ALLOC_N(char, length); strcpy(strp->buf, HELP); strp->size = length; return str; Is here the memory pointed by `buf' safe? Or will I need a function like that: void mark_buf(strp) struct string *strp; { rb_gc_mark(strp->buf); } Will the memory pointed by `buf' be deleted during GC? Or have I to implement a `free_string' method like that: void free_string(strp) struct string *strp; { free(strp->buf); strp->size = 0; /* Okay! paranoid. */ } [...] >When malloc() returns NULL, then the memory allocator invokes GC, then >tries malloc() again. If malloc() still returns NULL after GC, the >memory allocator gives up allocation, raises Fatail error. But that happens only if I use `xmalloc'. My question was, if my extension use `malloc' directly, and report back to me, that there was no enough memory available. Should I raise an fatal error then, or what kind of error you would raise? [...] >Hope this helps. I am on-the-way ;-) In the meantime... sorry for my bothering questions. > matz. \cle