A couple times on this list, I've read pleas for examples of
real Ruby applications that use Continuation objects. 

Ours is described here:

http://www.zenspider.com/dl/rubyconf2005/EmbeddedRuby.pdf
http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B75DF-4MT6KFX-H-7&_cdi=13037&_user=488091&_orig=browse&_coverDate=02%2F28%2F2007&_sk=999879998&view=c&wchp=dGLbVlz-zSkWb&md5=99829235a3aae38f50df899786b91af2&ie=/sdarticle.pdf

It's real enough, even if it's a little unusual :-)

We've started using Continuations to store checkpoints as Ruby
scripts execute.  These scripts control robotic manipulators, so there is
always the possibility of a failure, either due to a mechanical problem
or a coding error.  The protocols controlled by these scripts
often take hours to complete and consume expensive reagents.
Simply reexecuting them from their beginning in the event of an
error is rarely  a viable option.  So, when an error occurred, we used
to hack up a new script on the spot to recover from
the failure.  Now, using Continuations, we can usually
clear the error condition with a couple simple commands
and resume the execution of the script's failed thread
from its last recorded "checkpoint".

This all works surprisingly well and has been quite easy to implement.
A couple days ago I fixed a typo [that caused an unhandled NameError
two hours into a scripts execution], reloaded the effected method(s) and
resumed execution without losing any important system state!
Honestly, I wish I'd implemented this years ago.

Can anyone help answer the following:

1)  Does the Continuation object include a method to return its associated
     call stack analogous to an Exception object's :backtrace method?
   
     For now, I store the output of Kernel.caller() in my Checkpoints
     just after the callcc that stores the Continuation
     but I feel this must be very inefficient in time and space.
 
2)  If the answer to #2 is no, would it be easy & sensible to implement
      Continuation#backtrace or Continuation#caller ?

3)  Is there another way to implement the generic
     "checkpointing" described above that does not rely
      on Continuation objects, as their future in Ruby seems
     uncertain?  (Is their future still uncertain?)

-- 
 Brent Roman
 Monterey Bay Aquarium Research Institute