Comparing threads to assembler is a bit extreme. They can certainly be delivered in a highly abstracted, self-contained way (and you'd probably even call it by something other than threads to get the point across regarding the special nature I described... more like an AsyncObject or AsyncFunction than a full-blown thread).
One interesting possibility would be support for a "stackless" ActionScript (see Stackless Python, et al). If memory serves, stackless is more of a language thing than a virtual machine, i.e. it should be possible to implement a stackless variant of ActionScript on the existing AVM2 by simply providing compiler support. This is the kind of experiment I think we'll see when Adobe open-sources the Flex compiler. And I'd be very hesitant to dismiss multi-threading, even if it offered minimal benefit in the past (it admittedly offers more convenience in many scenarios than any actual performance gain). With the proliferation of multi-core processors, single-threaded applications are simply going to be "just as fast" regardless of how fast an overall CPU the user has... there are simply limits (in regards to reasonable cost of engineering, etc.) to when you start throwing more CPUs at the problem than faster CPU's, particularly in the many-process OS's of today. Of course, Flash already spawns threads for the most obvious use of threads: IO. This goes a long way to reducing the necessity for threading in Flash. And I'm not sure of it, but wouldn't be surprised if rendering and AVM2 run in parallel on separate threads (though they could just as likely be lock-stepped for simplicity). But, if Adobe really wants to keep pushing Flash Player as a platform of choice for RIA's (and similar software, like games), they're really going to have seriously weigh the issue of threads, even if it is some highly abstracted version of them -- at a *minimum* they'll need to eventually allow for the user to disable the execution cap that's currently in place, if no threading is ever provided. Otherwise, they'll be tossing a lot of potential applications to the wayside (where they'll be scooped by the .NET or Java). Troy. On 5/3/07, Ralf Bokelberg <[EMAIL PROTECTED]> wrote:
What about yield. This would make it easier to break things into smaller parts. Thread are the last thing i'd like to see in the Flash player. Ugly, complicated and errorprone. Like assembler. r. On 5/3/07, Samuel R. Neff <[EMAIL PROTECTED]> wrote: > > > 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] <careers%40blinemedical.com> > > -----Original Message----- > From: flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com<flexcoders%40yahoogroups.com>] > On > Behalf Of Manish Jethani > Sent: Thursday, May 03, 2007 11:14 AM > To: flexcoders@yahoogroups.com <flexcoders%40yahoogroups.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]<troy.gilbert%40gmail.com>> > 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. > > -- Ralf Bokelberg <[EMAIL PROTECTED]> Flex & Flash Consultant based in Cologne/Germany Phone +49 (0) 221 530 15 35
