[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
23 Dec 2000 16:07:35 +0100
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
Dirk Herrmann <address@hidden> writes:
> Hello everybody!
> Have you taken a look at the scm_remember issue again? I have the
> following compromise suggestion: We add the following functions
> /* If within a function you need to protect one or more scheme objects
> * from garbage collection, pass them as parameters to one of the
> * scm_remember_* functions below. These functions don't do anything,
> * but since the compiler does not know that they are actually no-ops,
> * it will generate code that calls these functions with the given
> * parameters. Therefore, you can be sure that the compiler will keep
> * those scheme values alive (on the stack or in a register) up to the
> * point where scm_remember_* is called. In other words, place the call
> * to scm_remember_* _behind_ the last code in your function, that
> * depends on the scheme value to exist.
> * Example: We want to make sure, that the string object str does not
> * get garbage collected during the execution of 'some_function',
> * because otherwise the characters belonging to str would be freed and
> * 'some_function' might access freed memory. To make sure that the
> * compiler keeps str alive on the stack or in a register such that it
> * is visible to the conservative gc we add the call to scm_remember_1
> * _after_ the call to 'some_function'. Note that this would not be
> * necessary if str was used anyway after the call to 'some_function'.
> * char *chars = SCM_STRING_CHARS (str);
> * some_function (chars);
> * scm_remember_1 (str); // str will be alive up to this point.
> void scm_remember_1 (SCM obj1);
> void scm_remember_2 (SCM obj1, SCM obj2);
> and thus habe a uniform possibility to protect one or more objects
> from garbage protection, plus we don't get conflicts with the current
> definition of scm_remember.
> However, I still recommend to deprecate scm_remember in its current form
> because of the much more irritating implications with regard to object
I think this is a good suggestion. The semantics of scm_remember
really are hairy and scm_remember_1, etc should be easier to
understand, *provided* that the user understands that it has to use
them as the _last_ reference to some object.
Maybe we could give them more descriptive names like
void scm_remember_upto_here_1 (SCM obj);
void scm_remember_upto_here_2 (SCM obj1, SCM obj2);
void scm_remember_upto_here (SCM obj1, ...);
The function scm_remember should be deprecated alright.
Dirk could you make that change? We should also replace all uses of
scm_remember in Guile itself, of course...
- Re: scm_remember,
Marius Vollmer <=