Torsten Curdt wrote:
If you want to get rid of the of the method
lookup you do need to pass in the Runnable
also to the continueWith ...not sure if I
like that.
No, I don't think you have to. That Runnable object is a part of
Continuation already. The continueWith method can look it up from
there. Specifically, it already retains a reference to that object
in Stack. We just need to make it explicitly accessible (instead of
fiddling with references in stacks to get to it.)
I *do* think you have to :)
..think about the serialization. The continuation
has been restored. THERE IS NO REFERENCE TO A METHOD
OR RUNNABLE. Please check with the current implementation.
For debugging you can add logging to see what's been put
onto the stack.
Here's my reasoning. Please tell me where I made a mistake. Let's take
the serialization test case as an example.
Suppose Calculator implements a Runnable and its run method is the entry
point. We run Calculator and it suspends. We start the stack capturing,
and when a new continuation object is returned, it contains this
runnable object. You can see this in the output from XStream that I
attached.
In particular, because the Runnable object invoked is always the very
bottom of the stack trace, you can always access it at a top of the
rstack. You are throwing it away right now, but you just need to keep it
little longer. The object is also on the ostack, although this is less
accessible (because it's not always on top.)
When you serialize a Continuation, therefore, the Runnable object also
gets serialized. You deserialize it back, you get the Runnable object back.
So when you hit Continuation.continueWith with a deserialized
Continuation object, all you need to do is just to access the top of the
rstack to get the Runnable object back, then invoke its run method.
Well ...that's not the point. I really do
think you have to pass in the Runnable or
Method to "continueWith" ...if you don't have
a lookup. That's why I don't like this either:
startWith(Runnable, ContinuationContext)
continueWith(Runnable, Continuation, ContinuationContext)
I hope the above argument convinced you that you don't have to pass in
Runnable to the continueWith method.
Or let's put this in another way. If I can successfully change the
Continuation API to:
startWith(Runnable, ContinuationContext)
continueWith(Continuation, ContinuationContext)
and make the serialization test work, would you be willing to accept the
changes? The quickest way to find out if this is doable or not is to
actually do it.
Unlike Continuation, Fiber is a mutable object. It updates itself
as you continue execution. That's why sometimes you want a "fork"
to create an identical copy.
..that also means for persistence you would
have to serialize the Fiber object, too. Hmm...
Yes, if you choose to use a fiber, yes.
Fiber.fork doesn't deep-copy Continuation, as Continuation itself
doesn't need to be copied. It's just Fiber object that needs to be
copied, hence the use of clone().
Hmmm... why do you need a mutable object at all?
It's not that I want a mutable object. It's convenient to have a
representation for a "thread" of execution, and such representation is
going to be mutable because execution state changes as it runs.
Use in Cocoon is special in the sense that it keeps the continuation
object at every yield point. Neither a workflow engine nor an agent
container does this.
Sure ...but don't you think it's more important
the guts are working properly before abstracting
the further abstracting the API?
If it's not working properly, yes. I just assumed that it is working
(besides the monitor issue.) Is there any other known problems?
The current BCEL one seems to be working, so it's not very high
priority for me to rewrite javaflow by using ASM. Besides, I doubt
if I can be of any help when it comes to porting javaflow from BCEL
to ASM. That part is the guts of javaflow and it takes you to
change it.
..too bad - hoped you could help me there as well :)
I saw that the instrumentation algorithm can be probably optimized (for
example, no need to instrument StringBuffer.append() operation, share
the stack capturing code, etc) Now that I actually saw the decompiled
byte code, I'm more willing to change it than before.
Comeon ...it's not big difference whether it's
in your codebase or inside the javaflow codebase,
isn't it?
..I am not saying "no" but "convince me" ;)
It's not a big difference, in a way, yes. But on the other hand, if none
of the changes that I really care is accepted, it's very difficult for
me to help.
I need your help to find the middle place we can meet. I suggested to
get rid of MethodLookup in favor of Runnable, and you didn't like it. So
I suggested to keep it as is and add what I wanted as another class, and
you didn't like it either.
I spent time rewriting the Cocoon portion just to show you how it can be
reasonably done. I think I gave a reasonable set of justifications for
each proposal, like simplicity, ease of use, etc.
What do you need to be convinced of? That this is doable? Or that this
is beneficial? Or is it something else?
--
Kohsuke Kawaguchi
<org.apache.commons.javaflow.Continuation>
<methodName>main</methodName>
<stack>
<istack>
<int>1</int>
<int>18</int>
<int>0</int>
<int>0</int>
<int>0</int>
<int>0</int>
<int>0</int>
<int>0</int>
<int>0</int>
<int>0</int>
</istack>
<fstack>
<float>0.0</float>
<float>0.0</float>
<float>0.0</float>
<float>0.0</float>
<float>0.0</float>
</fstack>
<dstack>
<double>0.0</double>
<double>0.0</double>
<double>0.0</double>
<double>0.0</double>
<double>0.0</double>
</dstack>
<lstack>
<long>0</long>
<long>0</long>
<long>0</long>
<long>0</long>
<long>0</long>
</lstack>
<ostack>
<org.apache.commons.javaflow.testcode.Calculator>
<field>6</field>
</org.apache.commons.javaflow.testcode.Calculator>
<org.apache.commons.javaflow.testcode.SomeReference/>
<null/>
<null/>
<null/>
<null/>
<null/>
<null/>
<null/>
<null/>
</ostack>
<rstack>
<org.apache.commons.javaflow.testcode.Calculator reference="../../ostack/org.apache.commons.javaflow.testcode.Calculator"/>
<null/>
<null/>
<null/>
<null/>
</rstack>
<iTop>2</iTop>
<fTop>0</fTop>
<dTop>0</dTop>
<lTop>0</lTop>
<oTop>2</oTop>
<rTop>0</rTop>
</stack>
<root reference=".."/>
</org.apache.commons.javaflow.Continuation>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
