Had to go change a diaper (not mine). I'll also add that I think of network I/O as asynchronous and non-blocking. Some folks say that network requests don't actually go out until your code stops running. To me, it doesn't really matter when they go out, because the results will not come back while my code is running.
Whether or not threads do spin up to handle some of this stuff, the result is always an event, and such events, and any other events like frame, timer, mouse, keyboard are effectively queued. When your code stops running, the player will either render or run the handlers for the next event. The fact that a network request returns while your code is running does not cause your code to be interrupted. Your code must finish, then the next event will be handled. Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Saturday, August 29, 2009 3:08 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Race conditions when event handlers triggered from different targets I doubt we'd document the exact behavior of some of these calls. First, we'd want to reserve the right to change them as the underlying platforms change, and further, the implementation of some things depend on the platform and the goal of the player is to abstract them from you. Your only hooks into the player are via ActionScript (and PixelBender, I suppose), so the abstraction presented by the ActionScript VM) and PixelBender APIs are all you should really be depending on. I don't know which engineers said that URLLoader.load goes into another thread. I don't know why it would need to since once the server request has been made asynchronously, there isn't much to do until the result comes back, and once the result comes back, maybe they'd spin the conversion out to another thread, but I don't see that in the source (although it is hard to read) and if it did, I think we'd see the player using multiple cores on multicore machines which I don't. Asynchronous calls to the OS or Browser host may in turn cause the OS and/or Browser to spin threads, but again, that's not really under your control and may differ by environment. We try not to worry about those things on the SDK team. What we do keep in mind is that the we're running in a single-threaded, non-blocking, deferred rendering environment, and because we don't use script blocks on symbols, Flex is essentially event-driven, and does not use the timeline, except for the preloader. That means that, once the SWF starts, enterFrame, render, mouse, keyboard, network or timer events start a bunch of code running without interruption and when that code finishes, another event will run code, or the player will update the screen. That's pretty much how I think of it. Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of mike_slinn Sent: Saturday, August 29, 2009 1:22 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Race conditions when event handlers triggered from different targets > Yes, the Player has multiple threads. But the ActionScript Virtual Machine > executes in only one of them. According to the Flash Player engineers that I have spoken to, some ActionScript method calls are handed off to other threads, for example URLLoader.load(). It would be helpful to read a more detailed and complete explanation of the Flash Player's threading model, and how functionality exposed by ActionScript VM is scheduled. Mike
