0 Replies Latest reply on Feb 15, 2007 8:05 AM by Johnathan_Conley

    Continuations support?

      I was wondering if there are any plans to consider continuation
      support in flash/flex? ...predominantly to support the concept of a
      smarter "Thread.sleep(n)" without blocking or disrupting the
      single-threaded execution model.

      For context, here is a "sleep" pseudo-example how it might look conceptually.
      The example's meaningless result, and for loop are a weak case to show how
      these complicate/invalidate any use of setTimeout in the current
      flash/flex model.

      function example():int {
      int result = 0;
      for (c:int=1; c<5; c++) {
      trace("after 5 seconds");

      function sleep(sleep_millis:int) {
      var savepoint:Continuation = Continuations.new(); // creates a
      holder that will capture the execution stack state at the next suspend()
      setTimeout(function(event:Event):void {
      Continuations.resume(savepoint); // resumes the
      saved execution stack

      For my purposes, I am writing a general-purpose tool for developers
      that would locate one or more components in the UI hierarchy (by some
      criteria), then return those components so they could interact with them.
      In searching for said components, I have come across embedded
      SWFLoaders which are not yet finished loading/reloading, and sleep()
      (via continuations) would allow checking it's state periodically and
      not disrupt the execution stack, callers code or block the overall

      From a runtime perspective, I assume there is an "EventManager" and one event
      thread that dispatches one event at a time off the queue. Basically, if
      Continuations were introduced, the current event thread (Thread1) would
      sleep() when Continuations.suspend(x) is called, but also tell the
      EventManager to create a new thread (Thread2) to continue processing the event
      queue. When Continuations.resume(x) is called, Thread2 would halt while Thread1
      resumes and finishes... then Thread2 would continue. So while there are
      physically 1+ threads present, only 1 is active at any given time (managed
      by the EventManager)