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

Re: continuations and threads

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.



>>>>> "Jim" == Jim Blandy <jimb@xxxxxxxxxxxx> writes:

>> I understand what you're saying, but you haven't addressed my concern
>> (re-quoted above) at all.

Jim> I'm sorry I misunderstood you.

>> >> I *want* the C stack to be unwound, so that the Scheme
>> >> heap references in the C activation records get freed

Jim> Well... I *don't* want the C stack to be unwound --- yet.  :) That C
Jim> stack frame is still live, because S2 might yet return.  So its heap
Jim> references should not be freed.

Jim> The discipline I've described has more expressive power than the one
Jim> you described.  In order to provide that additional power, we have to
Jim> keep that C stack frame around longer, because we can't be sure yet
Jim> that we don't still need it.  It's still potentially relevant to the
Jim> computation, so we can't throw it away.

Sure, but I don't think SML/NJ actually *detects* that it's still
relevant.  (The GC could, I guess.)  This means that the retained C
frame may still keep data alive which is really dead.  This might
create a space leak.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla