[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 contain all messages, not just those from before July 7th, 2015.

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:

        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;


	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 x;
            scheme_value y;
          } l;



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




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