Having already argued against it, here is an argument that reusing
RetContinuations is acceptable.
Parrot is not a side-effect free language. So _every_ continuation
goes out with a social contract.
Something like "Use this continuation once, great, but use it twice,
and things are _so_ undefined, and the user _really_ won't like it",
seems a perfectly valid, even normal, caller contract.
Eg, I add 2+2, write the result to an open file handle, then _close_
the file handle, and putter off. Sure, add has the power to return
more than once. So the file handle doesn't get gc'ed. But it has
mutated into something which goes boom when written to. And if/when
bad things happen because add returns twice, well, we tell the user
"it's add's fault! Or someone add called! It's not _our_ fault.".
Given that, it seems reasonable, for instance, to use the same normal
Continuation for two adjacent method calls, and wrap demultiplexing
logic around the label where the continuation lands. "Is this the
first time the continuation has returned, then save the return value,
and do the second method. If this is the second time, we're done,
putter onward". If this > 2nd time, go boom.
And if we can do _that_, well, why bother with the demultiplexing?
Just mutate the Continuation, telling it now to return to label2
rather than label1.
And RetContinuation segfaulting when used twice becomes acceptable
behavior under this model. Sigh.
So, if you buy all this, it seems
(1) RetContinuation is a valid optimization on Continuation.
It is defended against multiple invocation by social contract.
A mechanism which of course makes it hard to find bugs.
(2) RetContinuation pmc's _can_ be reused.
Providing even more bug cover.
(3) One might amortize the construction cost of a Continuation by
using it for a couple of calls, perhaps making it competitive
with RetContinuation. Also bug cover.
Caveats. It is not clear to me how much stuff one can actually do
before the state a Continuation captured ceases to be acceptable. If
it is even if it is possible to set up the second method call. So (3)
may not work.
If one does reuse RetConts, one really wants an easy way to globally
turn this off, and instead have RetConts croak if reused.
I nominate this optimization for the "Winter 2004 tweak most likely to
make parrot unstable and undebuggable" award. ;) But perhaps if we can
live with it, we'll be running fast enough to set this optimization
focus aside, and get back to working on making parrot actually usable.
With real use, we'll have real loads to do optimization against.
Blech.
Mitchell
