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

> >> >> 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.
>
> Yes, I thought about that, but it makes the code more broken up and
> synchronisation of what happens becomes more difficult. In a way, it moves
> the difficulty from that of implementing safe pre-emptive threading to the
> "userspace" code. But I guess it is a work-around.
>
> Is it possible to use JavaScript to load an <iframe> and make a separate
> function trigger once the iframe has been loaded? Something like
>
> <IFRAME src="http://someurl" onLoad="MyFunction">
>
> Will that work?

No. <iframe> doesn't do onload. I think you have some deep misconceptions
about single-thread architecture. It makes things easier, not harder, unless
you are trying to simulate multi-thread architecture in it. Work with the
grain.

> >> 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.
>
> I have already implemented a prototype of this in a server based (CGI)
> application. I am now hoping to move as much of the work as possible to
the
> client in order to save the resources. It can be very hard on both the
> server and it's bandwidth proxying everything. If the data can travel from
> the source directly to the client, it makes the whole system much more
> distributed and scaleable.

You have some profound structural inefficiencies, it sounds like. Moving
them to the client is not a solution. I contend there is a better way to
think about the problem.

http://www.crockford.com/

.