Hi,
This is accurate, but here are a couple
more fine-grained comments:
- When
the player is run inside a browser, the player’s main thread is
actually the browser’s main thread. This is the reason that the ‘script
is taking a long time’ dialog is critical; it wouldn’t do to
have a slow script freeze your browser. In the future, one could imagine the
player being started and run in its own thread rather than in the browser’s
main thread to avoid this sort of thing.
- Networking:
When network requests are finally made at the end of the main loop, a new
thread is fired up internally within the player and the request is made in
purely synchronous fashion. The results are reported by that new thread
synchronously, dumped back onto the stack of events and data that the main
thread will check the next time it loops around. So the main thread notices
the results asynchronously, and the results are therefore reported to the
ActionScript callback asynchronously, but the network operation itselfis
synchronous and does occur in a new dedicated thread within the player
|
