You can always write some kind of wrapper, so you don't have to mess
around with empty
movieclips, and onEnterFrame, etc.
function caluculateStuff()
{
// set up any data needed for calculation
// ...
TaskManager.forloop(loopFunction, 1, 10, finalFunction);
function loopFunction(var i:Number)
{
trace("calculating number: "+i); //traces out 1 thru 10
}
function finalFunction()
{
trace("calculation complete!");
}
}
Then internally in TaskManager, you only run 1 loop per frame, or you
could use getTimer() to measure how long it is taking, and do as many
per frame as you can, without slowing things down too much. It's
slightly more typing than a simple for loop, but it's not that bad.
I'll leave the implementation of TaskManager as an exercise for the reader :)
-David R
On 12/7/05, Chris Allen <[EMAIL PROTECTED]> wrote:
> Hahaha,
>
> Okay your point is well taken. Especially since I am currently working on
> fixing a multi-threaded Java socket application at the moment.
> Multi-threaded programing isn't a walk in the park, that's for sure. But,
> with that said, depending on how Scott implements his MovieClip approach it
> might be a lot cleaner than doing onEnterFrame() all over the place. It
> certainly sounds like a legitimate approach to me.
>
> -Chris
>
> On 12/7/05, A.Cicak <[EMAIL PROTECTED]> wrote:
> >
> > Believe me multithreding is lot harder to debug, read and maintain in most
> > cases assuming that onEnterFrame is not made
> > in way that you put 20 loops all in one function (onEnterFrame) . You
> > could
> > make object (MultiLoop) which has method Update, some private counters,
> > etc.
> > and for each problematic loop you just make object MultiLoop, define its
> > Update method, add it to array, and in on enter frame loop through that
> > array and for each element call Update. In this way you could even do
> > stuff
> > like set priority to each loop, and for example call update in each pass
> > same number of times as is MultiLoop.Priority value. Code to process all
> > loops including priority support wouldnt be longer that 10-15 lines of
> > code,
> > and thats only thing you put in onEnterFrame. Although in real world
> > program
> > should be designed so there are not too much "problematic loops" anyway.
> >
> >
> > "Chris Allen" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > On 12/7/05, A.Cicak <[EMAIL PROTECTED]> wrote:
> > > I dont understand how your UI could lock in the first place? Sockets and
> > > sounds are already working in another thread and all other code which
> > > could
> > > lock the UI (like some long loops, etc.) can be made by "emulating" loop
> > > with onEnterFrame and few
> > > counters.
> >
> > Yeah, but onEnterFrame and counters make for some pretty nasty code
> > that is hard to read, debug, maintain, etc...
> >
> > >
> > > "Scott Hyndman" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]
> > > Windows 3.1 was single threaded. As I understand it, programs would hook
> > > into the event loop and be given a handle. While they held the handle,
> > > they could run their own code, but they were supposed to release it when
> > > they were finished to allow other running programs to use it.
> > >
> > > I guess what I'm trying to say is quite a bit you can do without
> > > multiple threads.
> > >
> > > And just as a side note, I came up with an interesting idea today on how
> > > to emulate multiple threads in Flash. Just use more than one movie! Talk
> > > between the UI movie and the background worker movie with a
> > > LocalConnection object, and you're in business. No more UI lock.
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Boon
> > > Chew
> > > Sent: December 3, 2005 8:24 PM
> > > To: Flashcoders mailing list
> > > Subject: [Flashcoders] Flash is a single-threaded app? Maybe it's just
> > > theAVM? or...
> > >
> > >
> > > I have read in this forum that someone loosely coined the phrase
> > > "Flash is a single thread app", it's hard to imagine something as high
> > > performance and intricate as Flash to be a single-threaded app.
> > >
> > > So I started to take the above statement to mean that the Actionscript
> > > VM executes all the code in a sequential fashion but that Flash player
> > > itself is multithreaded, is that a right assumption?
> > >
> > > And what about code that are asynchronous in nature, such as sound
> > > playing ( new Sound(), onSoundComplete), server-side call return (such
> > > as LoadVars, XML.onLoad)? Are these all happening in the single thread
> > > of code execution?
> > >
> > > Looks like a book on Flash and AVM Internal would be nice. :)
> > >
> > > - boon
> > >
> > >
> > >
> > > ---------------------------------
> > > Yahoo! Personals
> > > Single? There's someone we'd like you to meet.
> > > Lots of someones, actually. Try Yahoo! Personals
> > > _______________________________________________
> > > Flashcoders mailing list
> > > [email protected]
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > > _______________________________________________
> > > Flashcoders mailing list
> > > [email protected]
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > >
> > >
> > > _______________________________________________
> > > Flashcoders mailing list
> > > [email protected]
> > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> > >
> > _______________________________________________
> > Flashcoders mailing list
> > [email protected]
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> >
> >
> > _______________________________________________
> > Flashcoders mailing list
> > [email protected]
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> _______________________________________________
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
