RFC: Actions without barriers
Bob Rogers
eliminating the continuation barrier from action invocation: Simply
call the action using the original continuation instead of creating a
new RetContinuation. The original continuation, I reasoned, should be
re-entrant after having the dynamic environment partially restored.
Unfortunately, it's not that easy. The trick is that you need to
pass values from the original context, not the one that is exiting. And
exception handling is, well, exceptional: The values come from C code,
and not any context. So I had to add a 'payload' slot to struct
Parrot_cont in order to remember the exception; I had been hoping to
avoid extra state. Furthermore, there is no way for the vtable method
of a superclass to abandon the rest of the subclass method, so I used
some flag-setting kludgery to hack around that [1].
And it doesn't even quite work; in r15040, I get the following
additional test failures:
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------
t/compilers/imcc/syn/pcc.t 1 256 21 1 4.76% 8
* t/library/mime_base64.t 1 256 552 1104 200.00% 1-552
t/op/gc.t 1 256 22 1 4.55% 13
t/pmc/eval.t 1 256 21 1 4.76% 19
* t/pmc/resizablestringarray.t 1 256 173 326 188.44% 11-173
(The ones marked with "*" also have some failures in vanilla r15040.)
So what I want to know is: Do you think this approach is worth
pursuing? I would certainly make it work before committing it, and
would also want to make the flag-setting hack prettier (if I couldn't
eliminate it altogether). There's also some "proxy" stuff I think I can
get rid of. So it wouldn't be quite so ugly. I just want to know if
you think it is worth the trouble.
Or, I could sit tight and wait for a better way to return values from
C, since that is what the handler-calling code needs to do, before or
after PDD23 . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] I also merged Error_Handler:invoke into Continuation:invoke; it
actually reduces the code volume, but flattens the abstraction,
which doesn't feel quite right. But the point of the existing
Error_Handler:invoke is to return values from C, which ought to be
handled generally anyway. And I assume EH can go away after PDD23,
replaced with a general Continuation. In fact, it may even be
possible to get rid of it now.
Allison Randal
> Almost two weeks ago, I had what I thought was a clever idea for
> eliminating the continuation barrier from action invocation: Simply
> call the action using the original continuation instead of creating a
> new RetContinuation. The original continuation, I reasoned, should be
> re-entrant after having the dynamic environment partially restored.
>
> Unfortunately, it's not that easy. The trick is that you need to
> pass values from the original context, not the one that is exiting. And
> exception handling is, well, exceptional: The values come from C code,
> and not any context. So I had to add a 'payload' slot to struct
> Parrot_cont in order to remember the exception; I had been hoping to
> avoid extra state. Furthermore, there is no way for the vtable method
> of a superclass to abandon the rest of the subclass method, so I used
> some flag-setting kludgery to hack around that [1].
I can see why the solution was tempting, and I'm glad you tried it out.
I can also see why you paused to ask if it was worth continuing. Your
instincts are right, this solution gradually pushes further and further
from where we want to be.
Out of the possible hacks we could do, I'd rather go for the hack of
providing a way to create a new RetContinuation from within the C code
(even if it's a special kind of return continuation with the same
interface, but a different set of internal actions to satisfy the
interface).
> [1] I also merged Error_Handler:invoke into Continuation:invoke; it
> actually reduces the code volume, but flattens the abstraction,
> which doesn't feel quite right. But the point of the existing
> Error_Handler:invoke is to return values from C, which ought to be
> handled generally anyway. And I assume EH can go away after PDD23,
> replaced with a general Continuation. In fact, it may even be
> possible to get rid of it now.
Can you make this a separate patch, so we can review it independently?
I'm not sure we want to do it, but it's worth considering, on the
"Distinction vs. Reuse" design scale.
Allison
Bob Rogers
Date: Sat, 28 Oct 2006 22:50:57 -0700
Bob Rogers wrote:
> Almost two weeks ago, I had what I thought was a clever idea for
> eliminating the continuation barrier from action invocation: Simply
> call the action using the original continuation instead of creating a
> new RetContinuation . . .
I can see why the solution was tempting, and I'm glad you tried it out.
I can also see why you paused to ask if it was worth continuing. Your
instincts are right, this solution gradually pushes further and further
from where we want to be.
Out of the possible hacks we could do, I'd rather go for the hack of
providing a way to create a new RetContinuation from within the C code
(even if it's a special kind of return continuation with the same
interface, but a different set of internal actions to satisfy the
interface).
Hmm. I had thought this was what I was attempting, in a lightweight
sort of way, without creating a new class. I'm not sure that creating a
new class would help, but it's certainly worth considering. Perhaps the
options will be clearer when we're farther down the PDD23 road.
> [1] I also merged Error_Handler:invoke into Continuation:invoke; it
> actually reduces the code volume, but flattens the abstraction,
> which doesn't feel quite right. But the point of the existing
> Error_Handler:invoke is to return values from C, which ought to be
> handled generally anyway. And I assume EH can go away after PDD23,
> replaced with a general Continuation. In fact, it may even be
> possible to get rid of it now.
Can you make this a separate patch, so we can review it independently?
I'm not sure we want to do it, but it's worth considering, on the
"Distinction vs. Reuse" design scale.
Allison
You want a patch that just gets rid of Error_Handler? This might be
messier without the other changes (by "now" I meant "in a future version
of this patch"), but I'll give it a try. Not this weekend, alas.
-- Bob
Allison Randal
>
> Out of the possible hacks we could do, I'd rather go for the hack of
> providing a way to create a new RetContinuation from within the C code
> (even if it's a special kind of return continuation with the same
> interface, but a different set of internal actions to satisfy the
> interface).
>
> Hmm. I had thought this was what I was attempting, in a lightweight
> sort of way, without creating a new class.
AFAICT, you're going even farther than that, doing it without creating a
new object.
> I'm not sure that creating a
> new class would help, but it's certainly worth considering. Perhaps the
> options will be clearer when we're farther down the PDD23 road.
Indeed, the more we get implemented of the current Exceptions PDD, the
better we'll be able to shake down the system and explore the edge cases.
> You want a patch that just gets rid of Error_Handler? This might be
> messier without the other changes (by "now" I meant "in a future version
> of this patch"), but I'll give it a try. Not this weekend, alas.
Not urgent. It may turn out that the experiment is really only useful
with this solution.
Thanks!
Allison
Bob Rogers
Date: Sun, 29 Oct 2006 22:52:03 -0800
Bob Rogers wrote:
> You want a patch that just gets rid of Error_Handler? This might be
> messier without the other changes . . .
Not urgent. It may turn out that the experiment is really only useful
with this solution.
In the event, I think that is true. Folding the Error_Handler hackery
into Continuation could be done in either of two ways, but the general
way would involve inventing a whole new mechanism for C code (i.e. the
error signaller) to return results via a continuation, while the simple
way just moves the hackery into a different place without much gain.
And it may be that Error_Handler is useful even if it is not that
different from Continuation. If the continuation object was passed to
an action when unwinding, testing the class of the object could be much
more informative than the current practice of passing a simple boolean.
So perhaps Error_Handler is worth keeping, at least for now. (Though
maybe ExitContinuation would be a more general name for it.)
-- Bob