[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

more on GC issues

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 are here. Eventually, the entire history will be moved there, including any new messages.




I mentioned earlier that return values should really be via 
return parameters.

Argument parameters should be via references (pointers) as well:
otherwise, people can just recreate the same problem:



	scheme_value
        my_helper_fn (scheme_value * a)
        {
          scheme_value a_copy;

          a_copy = *a;

          a = SCHEME_NULL;
          return a_copy;
        }


and later:

        /* GC-unsafe code:

	x = SCHEME_CAR (my_helper_fn (&some_var));


With the changes I'm suggesting, one couldn't write my_helper_fn at
all and would have to write calls like:


	SCHEME_CAR (&x, &some_var);


Also, direct assignment to protected local variables should be
forbidden.   An incremental GC, for example, might want a write
barrier there.   So, not:

	scheme_value x;
	scheme_value y;

        [...]

        x = y;


but

	SCHEME_LSET (&x, &y)

As a matter of convenience, I think that GCPROing individual variables
is a bother.   I prefer an interface like:


	{
          struct foo_frame
          {
            SCHEME_VALUE_FRAME;

            scheme_value x;
            scheme_value y;
          } l;

          SCHEME_PROTECT_FRAME (l);

          [....]

          SCHEME_CAR (&l.x, &l.y);
          SCHEME_LSET (&l.y, &l.x);

          [...]

          SCHEME_UNPROTECT_FRAME (l);

         }

Also, SRFI-50 doesn't discuss the interaction of GCPROing a variable
with initializing, but it needs to.


-t