cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29308] - issue with javaflow continuations
Date Wed, 02 Jun 2004 04:25:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29308>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29308

issue with javaflow continuations





------- Additional Comments From dustbin777@yahoo.com  2004-06-02 04:25 -------
why is it failing if it is not an inner class but just a package class (not
public) as outlined in the first code sample in initial bug report ?

I would favour your idea of using a regular expression in class loader to
determine which classes need to be instrumented. This is because, if an end
client is using the continuations based third party set of classes, it will be
really difficult for him to determine which classes needs continuations and
which dont. Although it is inefficient perf wise, still it is worth the
convenience. It would be nice if sun folks realize the importance of
continuations and provide a framework to transparently migrate the current stack
 and program counter for execution. 

I am toying with the idea of using this continuation framework with Java NIO so
that we can get seemless transparent asynchronous I/O framework with programmer
coding sequentially. This way, we can emulate a socket which is internally
asynchronous but for outside world, might appear blocking. Although there is a
hidden cost of continuation stack capture etc.,. if we code the I/O framework
sensibly (doing enough buffering in async I/O layer before passing the control
back to program), the programming convenience outweighs the performance drop a lot.

Mime
View raw message