Subj : Re: Threading in JavaScript To : comp.lang.javascript,netscape.public.mozilla.jseng From : Steve van Dongen Date : Sun Feb 02 2003 03:53 am On Sat, 01 Feb 2003 17:40:17 +0000, Gordan wrote: >Douglas Crockford wrote: > >>> I take it that both SpiderMonkey and Rhino only provide a >>> single-threading environment? And there is no browser that actually >>> supports multi-threaded JS? >> >> Nope. For applications based on short bursts of event-driven activity, >> threading is less efficient and prone to deadlocks. What are you doing >> that requires preemption? > >I would like to download multiple files simultaneously, process them >independently, and then independently update separate objects in a page >(e.g. DIVs containing some HTML data stripped out from the downloaded >files). > >The reason why I want to handle them all independently is that the >application I am writing should scale to, potentially, hundreds of files >from which the relevant data is extracted. Unfortunately, the potential >latency on some sites can really hammer the performance, and one slow >download slows down the entire process, rather than just making one >specific DIV block take longer to generate. > >It is also not useful to have to wait for the whole page to be generated >before being able to do anything with it. It would be much more useful if >each finished part of the page could be used independently, while the >remaining sections are being processed (e.g. scrolling, clicking, opening >links in a new window/frame, etc.). > >I was thinking about working around this by using IFRAMEs instead of DIVs, >but I have found that the single-thread paradigm also spans frames within a >single browser instance. > >The only workaround I can think of is creating a Java applet or a >plugin/ActiveX control combo (I need the app to be cross-browser) that can >take a URL, or a list of URLs and start downloading them independently. >Then I could fudge the delay loop using a recursive setTimeout() based >function for polling the status, and working around the problem that way. >It wouldn't work around the parallel page generation issues, but it would >at least work around the issue of not being able to fork multiple >simultaneous downloads. > >The problem with this partial work-around is that I would have to write the >applets as well as the page generation code, but it is looking more and >more like I don't really have a choice. > >Can anyone suggest a better way of doing this in a browser (short of writing >the whole thing as an applet)? Sounds like you should look into XMLHTTP http://jibbering.com/2002/4/httprequest.html Regards, Steve .