From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Tue, 31 Jan 2006 14:01:42 +0100
Bob Rogers wrote: > From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]> > Yep. At least as long we don't have better support for creating > limited continuations that are able to return some results. > > I'm afraid I don't follow. What would you consider better? Limiting the callframe range, where the continuation can go. Currently creating a continuation is rather expensive, as all RetContinuations up the call chain are converted into full continuations. This is necessary because there is no further information about the usage of the continuation. It could be passed to 'main' and then 'jump' back. Thus all the intermediate frames have to be kept alive, because normal function return goes through these frames. Hmm. In this particular case, that doesn't actually make much difference. In order to implement certain classes of nonlocal exits, I'm creating a continuation and stuffing it into a lexical variable, and I notice that C<newclosure> also promotes the RetContinuation to a Continuation (though only for that frame). Worse, the closed-over frame is leaked entirely. (Is this what the "obviously leaks memory" comment in src/register.c is talking about, or are there other cases of leakage?) But I think I have a handle on what's causing this, and hope to propose a fix shortly. > But, FWIW, I am coming around to the view that continuations > shouldn't ever be invoked like this . . . I don't think that we can enforce this. Have a look at t/library/streams.t. I don't think that a compiler has the knowledge that it's compiling the invocation of a continuation instead of a plain subroutine. Well, mine does, but that doesn't mean much. ;-} Point taken. The tailcall syntax works, because it's just ignored by the continuation. leo Yep; and it also avoids making a useless return continuation, which is nice. -- Bob