So I tried to dig up some sort of formal article that described how the Player really operates but it turns out there isn't one.  That's something we'll look to rectify but in the meantime here's the high-level overview:

 

The Player is a frame-based system since it's originally designed for graphics and animation.  Whenever you see an animation or a button highlighting for example, multiple frames are passing by showing you different states.  One time for each frame the Player will execute code.  The entry point into that code is through event handlers which are specified by the Player.  Almost all of those event handlers are masked by Flex, instead we provide higher-level events.  So, when one of those event handlers fires your code will execute.  All ActionScript code executes in a single thread, you are never at risk of two threads running at the same time so there is no such thing as locking or waiting.  While your code is executing the Player will not draw either.  So if you have a loop that is taking a long time so your code doesn't exit the Player appear to slow down or hang.  This is why you might see warnings about a script taking too long to execute.  If you want to spread some processing out over a few frames so that your application appears more responsive you can use the doLater function which you can see in the docs.

 

OK, so what happens when you call a method that is going to send stuff over the network?  Essentially the Player will batch up those calls and when your code for that frame has finished (your event handler exits) it will go ahead and make all of those calls.  There is no guarantee as to the order of the calls, so if order is important you'll need arrange that yourself by waiting for the first to return before sending the second.  As those network calls complete events will fire for you to handle the results.  Each call return is its own event; those will not be batched up.  And thus the circle of life is complete J

 

HTH,

 

Matt

 

-----Original Message-----
From: sbyrne_dorado [mailto:[EMAIL PROTECTED]
Sent: Friday, May 07, 2004 9:45 AM
To: [email protected]
Subject: [flexcoders] Re: Remote object method execution sequence?

 

Matt,
Thanks for your reply.  I can't point out in the docs where it says it
because where it says it is in the upcoming book: Chap 20, Page 18
near the top:

"Due to the time-based "threaded" model that Flash Player operates on,
the physical call ot the server-side methods doesn't occur until the
getPortfolio() function call completes".

I have never seen in the Flex docs any statement of the threading
model; is there such a description?  I know when I was first reading
about the PendingCall usage I was somewhat taken aback because here
was so clearly a race condition that was being set up and the docs
were making no mention of it.  Nor did the docs seem to have any
statement about how to perform synchronized access to shared state
between threads, which further concerned me.

Is there any statement in the Flex docs that explains the threading
model?  And, is this threading model an explicit part of
Flex/ActionScript that we can count on going forward, or is it just a
near term implementation artifact?


--- In [email protected], Matt Chotin <[EMAIL PROTECTED]> wrote:
> You are correct that they would happen after 12.  If you can point
out in
> the docs where you think that's unclear it'd be appreciated.
>



Reply via email to