2 Replies Latest reply on Apr 13, 2011 11:23 AM by Flex harUI

    Flex Threading /Asynchronous Behavior

      I know this is a very silly question but still I request you guys to respond to this. Is Flex both single-threaded and asynchronous? If so, how can a programming model behave in both the ways? Please explain me with an instance, am getting cornered with this.
        • 1. Re: Flex Threading /Asynchronous Behavior
          Gregory Lafrance Level 6

          Well, Flex is single-threaded. Events are also asynchronous. The key is to know where to put code, for example when you make a data call to the backend, perhaps to a PHP script, after calling send() for an HTTPService, you can't just assume the data has been returned. So you might need to do something in the result handler method once you have verified the data has been returned and processed. Or you might call another function at that point in the result handler method. Or you might set a flag, for which a change watcher has been defined.

          1 person found this helpful
          • 2. Re: Flex Threading /Asynchronous Behavior
            Flex harUI Adobe Employee

            In single threading, you are guaranteed to know what code will execute in

            what order.  No other code can run that can affect the execution of your

            code.  This is not to say that some code you run won't go and do other

            things before returning, but those things are known.


            Asynchronous means that some request you make will result in a response at

            some unknown point in time later on.


            While those statements seem contradictory, it is managed by the runtime in a

            certain way.  Responses to asynchronous requests are queued up and the code

            that responds to them does not run until all of your other code has finished

            running.  That's how order of execution is guaranteed.  You can always know

            that the next line of code will run after the current line.


            What isn't guaranteed is, once your code finishes up, what code will run

            next.  The code that runs next might be responding to various asynchronous

            events and the order they execute will depend on the timing of those events,

            but once some code starts to run, it will run to completion before the code

            for the next event starts to run.


            No interrupting can happen.  And FWIW, the opposite is true, there is no

            "blocking" either.