Seth, Josh, The reason I have not used timers is because I can´t. The algorithms I am executing are not decomposable into discrete steps without titanic efforts. Evaluation of bitmap indexes in memory for intense relational algebra stuff.
I do have a class that encapsulates a pseudo-thread and allows me to process chunks... it goes a long way to support a hierarchical stack for recursion, facilities to manage context between calls, timers, and a even a way to plug into the suspend background processing stuff in the framework so it yields nicely to effects. But, it won´t do the trick this time. So, back to the multithreading... Is it totally impossible? Thanks, Aldo On Nov 19, 2007 8:43 PM, Josh VanderBerg <[EMAIL PROTECTED]> wrote: > > > > > > > I'd have to agree with Seth, though I would suggest using a timer, as > the setInterval function appears to be deprecated. > > In the past I've actually written a light weight class that > encapsulated the timer logic and handled storing state between > function calls. > > -- > Josh Vanderberg > vanderblog.typepad.com - Flex blog and open source flex components > > > > --- In [email protected], "Aldo Bucchi" <[EMAIL PROTECTED]> wrote: > > > > Hi Guys, > > > > I need to run an expensive computation in the background ( 2 seconds > > on a modern day laptop ) while keeping the UI responsive. For this > > matter I have tried creating a secondary application and communicate > > with it in a non-blocking way. I share my thoughts so far to see if > > anyone can help with this one. > > > > First, some approaches to create a secondary application: > > * Load a module at runtime > > * Publish a module from within a new Frame ( Gonzalez/Harui trick ) > > * Open another SWF altogether ( seems the safest best bet to me ) > > > > Some approaches to communicate between apps: > > * LocalConnection ( sync ) > > * Write/Poll a LSO ( async ) > > > > And to go from blocking to non-blocking communication ( maybe ) > > * Upon receiving a call start a timer and listen for the completion > > event. This should make the call return while leaving it up to events > > to start the real processing. > > > > Now, I haven't tried every combination yet, but so far I found some > > interesting results: > > > > I created two separate applications that talk through a > > LocalConnection. They use the timer trick ( upon receiving a call they > > set up a very short internal timer that will eventually start internal > > execution of the code ). If I open both SWFs in IE they effectively > > work as expected. I can start a very heavy computation on the > > secondary app while the first remains totally responsive to user > > events. Then I can make a reverse call and pass the results back. So > > far so good :) > > > > Firefox, however, is a show killer. No matter how I open the two apps > > ( tabs, apps, etc ) blocking occurs. > > > > Can someone from the flash player shed some light on this? > > This is not real multi-threading, it is simpler in the sense that I > > don't need synchronization. The contract is passing an input and > > waiting for a result. > > > > Now, even if I managed to pull this off with parallel applications... > > how would I materialize that setup in AIR? > > > > Thanks, > > Aldo > > > > > > > > -- > > :::: Aldo Bucchi :::: > > +1 858 539 6986 > > +56 9 8429 8300 > > +56 9 7623 8653 > > skype:aldo.bucchi > > > > > -- :::: Aldo Bucchi :::: +1 858 539 6986 +56 9 8429 8300 +56 9 7623 8653 skype:aldo.bucchi
