Re: RFC: Actions without barriers
From: Allison Randal [EMAIL PROTECTED] 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
Re: RFC: Actions without barriers
From: Allison Randal [EMAIL PROTECTED] 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
Re: RFC: Actions without barriers
Bob Rogers wrote: 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
RFC: Actions without barriers
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].
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 256211 4.76% 8
* t/library/mime_base64.t1 256 552 1104 200.00% 1-552
t/op/gc.t 1 256221 4.55% 13
t/pmc/eval.t 1 256211 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.
Index: src/pmc/retcontinuation.pmc
===
--- src/pmc/retcontinuation.pmc (revision 15040)
+++ src/pmc/retcontinuation.pmc (working copy)
@@ -88,6 +88,11 @@
struct PackFile_ByteCode * const seg = cc-seg;
next = SUPER(next);
+if (PObj_flag_TEST(private1, SELF)) {
+PObj_flag_CLEAR(private1, SELF);
+return next;
+}
+
Parrot_free_context(INTERP, from_ctx, 1);
#ifdef NDEBUG
/* the continuation is dead - delete and destroy it */
Index: src/pmc/continuation.pmc
===
--- src/pmc/continuation.pmc(revision 15040)
+++ src/pmc/continuation.pmc(working copy)
@@ -25,7 +25,60 @@
#include parrot/oplib/ops.h
#include assert.h
+void *
+Parrot_invoke_with_continuation_args(Parrot_Interp interpreter,
+ PMC *sub, PMC *continuation,
+ const char* sig, ...)
+{
+opcode_t *dest;
+parrot_context_t *old_ctx = CONTEXT(interpreter-ctx);
+parrot_context_t *orig_from_ctx = PMC_cont(continuation)-from_ctx;
+/* Mark ourself so that RetContinuation:invoke (if continuation is a
+ RetContinuation) doesn't immediately destroy the returning context;
+ we will need it to complete arg passing. */
+PObj_flag_SET(private1, continuation);
+
+if (continuation-vtable-base_type == enum_class_Exception_Handler) {
+/* create a new continuation, since Exception_Handler can't be recycled
+ this way. */
+PMC *eh = continuation;
+continuation = new_ret_continuation_pmc(interpreter, NULL);
+PMC_cont(continuation)-payload = eh;
+}
+
+interpreter-current_cont = continuation;
+interpreter-current_object = NULL;
+dest = VTABLE_invoke(interpreter, sub, NULL);
+if (!dest)
+internal_exception(1, Subroutine returned a NULL address);
+/* restore the original from_ctx (Sub:invoke bashes it). */
+PMC_cont(continuation)-from_ctx = orig_from_ctx;
+
+/* process args, if any. */
+if (sig *sig) {
+va_list args;
+
+va_start(args, sig);
+dest = parrot_pass_args_fromc(interpreter, sig, dest, old_ctx, args);
+
Re: RFC: Actions without barriers
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. 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
