guile-devel
[Top][All Lists]
Advanced

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

Re: broken GC


From: Rob Browning
Subject: Re: broken GC
Date: Sat, 06 Oct 2001 12:33:04 -0500
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7

Maciej Stachowiak <address@hidden> writes:

> * Look for all declarations of SCM variables
> * In the same block, but after the declarations, add the appropriate protect 
> call
> * At the end of the block, add the appropriate unprotect call (or else
> make protection work in such a way that it ends automatically when the
> variable goes out of scope).

This doesn't seem like it would handle structs.  Wouldn't we have to
parse and remember structs and typedefs if we allow structs that
contain SCM members to be declared as local variables or arg/return
values, or would we just forbid such usage?

Also, I just thought of what seemed like a simple way to handle most
of the plan old local SCM variable cases, but then I realized that I
probably don't understand the problem well enough yet.  When you have
a precise GC, who is responsible for marking/unmarking?  i.e. does a
function mark all its SCM args upon entry and unmark them before
returning, or is the caller responsible for that?  It seems like which
answers are acceptable depends in part on whether or not you want to
accomodate preemptive threading.

> Yes, C has a convoluted syntax compared to Scheme, but this is a
> fairly simple source-to-source transform. And it should indeed be
> possible to do the preprocessing first if necessary (most compilers
> have a preprocess only flag which should result in the same #defines
> being set as during compilation).

I think that if we go this route, we should probably require a full
preprocessing step using the target compiler and the same args that it
will be using to compile the final object code -- that is unless we're
going to do something (as some have proposed) that would require
people only use gcc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD



reply via email to

[Prev in Thread] Current Thread [Next in Thread]