Subj : Re: Threading in JavaScript
To   : comp.lang.javascript,netscape.public.mozilla.jseng
From : "Douglas Crockford" <nospam@laserlink.net>
Date : Sat Feb 01 2003 10:56 am

> >> 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).

That doesn't require preemption. Make a separate <iframe> for each document.
The scripts in the incoming documents will run when they are ready. They can
cause the data to be delivered to the main page. No evil threads are
required.

> 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.

Asking a browser to manage hundreds of connections is [asking for a kick in
the] nuts. That kind of stuff is best managed by a server. Servers can be
good aggregators. Browsers will only break your heart. Check out
www.statesoftware.com for a good server.

> 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)?

You have more [and better] choices than you know. The road you are currently
on is a hard and profitless on. I can consult on this if you need a guide.

http://www.crockford.com/

.