Re: scm_remember

[Marius Vollmer]

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
> protection.

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...