See the example in my blog ...which is actually taken from the Cocoon integration. (I think in there is also the link to the class) Would be great if you could also have a look into that class.I looked at Cocoon code you had in [1]. I didn't particularly see anything that made me rethink (IOW, I don't see anything that absolutely requires MethodLookup nor ContinuationContext instead of Runnable.)
Had a look into your implementation ...you have the "run" method delegating to the different methods. 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. I had similar idea in the beginning: startWith(Method, ContinuationContext) continueWith(Method, Continuation, ContinuationContext) What I did not like: Passing in of the Continuation already implies the Method. Beforehand the method was saved inside the Continuation object. But this does not work when it comes down to serialization. BTW: IIRC I needed to mark the static as transient for the XStream serialization ...but not totally sure.
But at the same time, I saw that you have some existing investments with the current javaflow Continuation API and it's very understandable that you don't want it to change.
Well ...it's still marked alpha so as long as it makes sense to me I am fine changing it. But TBH I currently would like to focus on the current bytecode rewriting stuff first before changing the API that much.
I see the desire to pass some contextual information to the invoked method, but that is a fairly common requirement even if you aren't using javaflow at all. javaflow just keeps it and stores it somewhere for later retrieval, which can be better done by the code that knows what the scope of a given context object is (like ThreadLocal, singleton, HttpSession, etc.)Just to make sure that I'm not missing something, I rewrote the JavaInterpreter and CocoonContinuationContext by using the ContinuationThread class (which I renamed to Fiber) instead of the current Continuation API. The only difference is that you now do:CocoonContinuationContext.getCurrent() instead of:(CocoonContinuationContext)Continuation.currentContinuation ().getContext()
Hm... it's shorter but I don't like it. It's not obvious where the context comes from. I would -1 that one.
See the attachments for the exact code. All in all, I didn't think this re-write is ugly, but that is always a subjective issue.
I don't understand this forking and cloning stuff - you don't need that. A continuation should be re-entrant and always create a new one as a result.
Anyway, I'm no longer too keen about convincing you to change the API of the Continuation class. If you like my rewrite, that's good, but if not, that's also fine with me. The current Continuation API makes the Fiber class implementation uglier, but that's not too big a problem.Instead, I'm hoping that you allow me to commit this Fiber class to javaflow, as this is what I primarily want to use in my code.
If you don't mind I would prefer if you keep that code in your codebase for now. Let's get back to that once we have the rewriting based on ASM in place. I would like to focus on the hard part first ;) Would that be ok for you? cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
