Ovidiu Predescu wrote:
> The big problem is that on the server side you have a thread *per
> request* waiting for the client to submit back a request. This model
> clearly does not scale!
Yes, exactly!
It has been proposed (and finally implemented in Java!) a non-blocking
I/O that might allow servers to handle more requests with the same
thread!
If the trend is evident even for runtime requests (that elapse pretty
quickly) you can imagine how painful would be to run such a system on a
loaded server with tens of thousands of concurrent users.
In fact, the solaris JVM is the most scalable in terms of threads, but
that runs until 4000 and then collapses on itself. That limit can be
*easily* reached in almost any average-load sites.
I would *not* be +1 in incorporating such a huge technology shift
without an architectural assumption that it would scale as well as the
rest of the cocoon architecture. And suspended threads are *clearly* not
the way to go.
> As for the ability to go back in time when the user hits the back
> button, this is not possible. Since there is no saved program state,
> the computation in the thread cannot be reversed to a previous state.
Agreed as well.
I think that these two points, together, show you evidently why we need
to something new (and something that supports real continuations!) even
if this, admittedly, will create some friction for the users that will
have to learn yet another language.
But we'll make sure it will be easy to learn, easy to use and the syntax
simple enough to learn by example only.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
