Thursday, September 14, 2017

Re: Iframe = multithreading ???

And one more thing, UI thread is only one for windowed / process application. So the clicks and generally Browser can be blocked when you will use time consuming operation on UI. If you will use e.g. setTimeout, no clicking etc, then it could work much better. Because this single UI thread must be "shared" by renderer of all frames / windows / documents visible to the user :-)

On Thursday, September 14, 2017 at 2:26:30 PM UTC+2, Paul Porombka wrote:
YES, totally agree. This is probably because Web Workers don't use any UI there. So they are probably better scheduled and "lighter", so works much better than forcing multithreading with IFrames :-)
But the concept is pretty nice, don't you think :-)

And to clarify. I was rather also considering a situation where I have a blank page in IFrame, without any UI elements, probably hidden frame, that will handle heavy operations, sent there from parent using postMessage. Because user interactions on UI can cause the behavior you observed. Then I would be closer to Web Workers. But definitely Web Workers are the right way in such situations. 

PS: Did you try your test using Web Workers for comparison?

On Thursday, September 14, 2017 at 1:21:48 PM UTC+2, Thomas Broyer wrote:

On Thursday, September 14, 2017 at 12:09:37 PM UTC+2, Paul Porombka wrote:
Hi Ben,

I see the time when you've posted the message and see the answers here, so I codn;t stop to write something here.
I will answer YES to your question, but it depends.

Generally, IFrame under the same domain is using the same thread. I don't know how it was at the time You've been asking, but now if you use IFrame with different origin (domain/host) it will use its own context, own event loop, so also ot will be separate thread.

While browsers are *allowed* to use different event loops for those "units of related similar-origin browsing contexts", it adds complications (see note in spec)
A quick test in my Chrome 61 on Linux shows that the same event loop is used for the iframe and parent browsing contexts loaded from totally different origins (I do heavy DOM manipulations in the iframe on the click of a button, and use a tight setTimeout loop on the parent that updates an element; when I click on the button in the iframe, I clearly see the parent "pause"; there are no communication by any mean between the pages; using and to have distinct origins for the same local server).
Same in Firefox 55.

So while it theorically *can* happen (is allowed by spec), it's not the case in practice.

Web Workers are the only (guaranteed, effective) way of "multithreading" in the browser. 
Currently a Web Workers concept is using this behavior. The problem was always with communication between those two frames, so it was also solved by "Messages". You are able to post a message to different ORIGIN and addEventListener to "message" event to receive such messages, and voila! You have two way communication between threads :-)

So if you create a code that can be executed separately in different IFrame, and exeute it in different ORIGIN, then YES you will get REAL multithreading, not single event loop, real muti-event-loop :-)

On Thursday, September 3, 2009 at 12:51:09 AM UTC+2, ben fenster wrote:
i was wondering that if by opening another module in an iframe tag the
code of that module runs in another thread ??
more over is the limit of 2 open http request apply on 2 diffrent
modules running in diffrent iframes ??

You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment