Subj : Re: Threading in JavaScript
To   : comp.lang.javascript,netscape.public.mozilla.jseng
From : Gordan <gordan@_NOSPAM_bobich.net>
Date : Sun Feb 02 2003 01:01 am

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

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

Regards.

Gordan

.