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.


Reply via email to