I'm looking for an answer that describes a "continuataion' mechanism in a web server vs. a programming language.
My understanding is that using continuations, it is trivial to have a "digits of pi" producer communicate with a "digits of pi" consumer, without explicit threading.
I've heard very good things about Jetty continuations, curious what others think.
I may have already found my answer, but I'm asking the question here anyway - for the record.
According to this page:
continuations will be replaced by standard Servlet-3.0 suspendable requests once the specification is finalized. Early releases of Jetty-7 are now available that implement the proposed standard suspend/resume API
I have not used Jetty yet, but it seems that with continuations the server is not required to keep a thread for each client where normally when the server is "holding off" (i guess blocking) on sending a response to a client that continuously polls it with AJAX it would need a thread for each client which would be a scalability problem.
how do they compare to the continuations found in programming languages?
They have nothing in common apart from the name. It's merely a mechanism for freeing the current thread by giving Servlet an API for storing and restoring its state, but it's all rather manually managed as opposed to real continuations, where the state is automatically inferred from the current context.
The prototypical example for cases where this makes sense is layered (composed) web services, where one service needs to make many requests to other services, and while these requests are made, the current thread is freed. Upon completions of the requests (which can be done asynchronously on some other threads), the servlet's resume method is called, which then will assemble the response from the results of the requests.