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.
This a very good point! Granted!
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 following problems are still on the TODO list o try/catch/finally o synchronized plus the code just asks for a cleanup and improvements. ...and I wanted to do that while porting to ASM.
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.
Hehe :) ..see?
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?
TBH ...I admit I've missed that we can use the instance from the stack. So you got a real good point! So you convinced me to go ahead with the Runnable approach. But still I am not to eager to have that Fiber class in the codebase ...at least for now. Can you live with that for the moment? cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
