Troy's suggestion would not require making everything thread-safe. He proposed a mechanism where by you could create a worker object which can act only on it's internal data which means thread safety is preserved. The other nice thing about this solution is it could be done through new player classes and would not require languages changes.
I agree threading is needed in the player and I like Troy's proposal. This is particularly true with Apollo apps which may not have a server immediately available. Sam ------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building Flex based products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -----Original Message----- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Manish Jethani Sent: Thursday, May 03, 2007 11:14 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Why aren't we allowed to process the event queue? (eg: like DoEvents) On 5/3/07, Troy Gilbert <[EMAIL PROTECTED]> wrote: > I think the best solution for Flash would be to introduce a first-class thread object. That way developers could spawn long-lasting tasks to a separate thread. If threading is introduced in the player, much of the Flex framework might have to be made thread-safe (as would any other Flash framework/lib/app out there). Currently all the code assumes there's only one thread of execution. My take is, if the task is too long/complicated, get it done on the server. Let's keep the player simple, please.
