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. >>> >> >> It's actually a bit more complicated: >> https://html.spec.whatwg.org/multipage/webappapis.html#event-loops >> 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 >> 127.0.0.1.xip.io and devd.io 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 google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Iframe = multithreading ???
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. >> > > It's actually a bit more complicated: > https://html.spec.whatwg.org/multipage/webappapis.html#event-loops > 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 > 127.0.0.1.xip.io and devd.io 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 google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Iframe = multithreading ???
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. > It's actually a bit more complicated: https://html.spec.whatwg.org/multipage/webappapis.html#event-loops 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 127.0.0.1.xip.io and devd.io 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 google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Iframe = multithreading ???
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. 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 google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Iframe = multithreading ???
ben fenster wrote: your answear is based on your knolage in js but i need an answear based on actual in depth knowlage in how browser work since each iframe act as an independed wep page and loaded sepertly No, you misunderstand --- if your code can see an iframe, that iframe must be part of the same Javascript VM as your code, and therefore must be part of the same thread. The spec requires it. Iframes aren't as independent as you think. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown. --- Carl Sagan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
ok thats sounds right but if thats true can i access static classes in the entrypoint module from a seperate module loaded in an iframe (that ofcours exists in the first module) ? On 3 ספטמבר, 03:00, David Given d...@cowlark.com wrote: ben fenster wrote: your answear is based on your knolage in js but i need an answear based on actual in depth knowlage in how browser work since each iframe act as an independed wep page and loaded sepertly No, you misunderstand --- if your code can see an iframe, that iframe must be part of the same Javascript VM as your code, and therefore must be part of the same thread. The spec requires it. Iframes aren't as independent as you think. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─http://www.cowlark.com─ │ │ They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown. --- Carl Sagan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
ben fenster wrote: ok thats sounds right but if thats true can i access static classes in the entrypoint module from a seperate module loaded in an iframe (that ofcours exists in the first module) ? Javascript will let you do it, provided the security rules let you (the page in the iframe must come from the same domain that your script does). I don't know whether it's possible to make GWT give you seamless access from Java, though --- you'd probably have to use Javascript trampolines. (Where one module explicitly exports stuff to the parent window, and then another module explicitly imports it again.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown. --- Carl Sagan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
There is just 1 JS thread. Regardless of URL or IFrame. The limit of max 2 connections is purely based on URL, not on per IFrame basis. IE8 allows more than 2, I forgot the exact number. To work around the connections limit you can spread web resources over different hosts in the same domain. Getting access to static classes in different IFrames can works but: 1) security restrictions might stop you from calling from one IFrame to another. 2) GWT code is obfuscated and can be totally different with every change you make. So in order to get access to some static classes, you will need to expose them through JSNI. On Thu, Sep 3, 2009 at 2:10 AM, ben fensterfenster@gmail.com wrote: another thing about the http request limitation most browsers rejects more then 2 simultinus requests to a spacific url and i wondered i its aplays to 2 diffrent browser windows (diffrent process in new browsers) and if iframe acts as new web page maybe the limitation grows by 2 for each iframe On Sep 2, 5:05 pm, ben fenster fenster@gmail.com wrote: your answear is based on your knolage in js but i need an answear based on actual in depth knowlage in how browser work since each iframe act as an independed wep page and loaded sepertly then the containing page made me wonder about how its being done without a diffrent thread ? and if another thread is envolved in loading then maybe the new thread is also responsible on running the js code contained in the page of the iframe ? On Sep 2, 5:46 pm, David Given d...@cowlark.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 ?? Nope. There is no way of getting access to multiple Javascript threads from a web browser, unless you use some sort of extension like Google Gears or HTML5 web workers. Every part of the Javascript VM that your code can see is part of the same event loop. more over is the limit of 2 open http request apply on 2 diffrent modules running in diffrent iframes ?? Don't know about this one. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─http://www.cowlark.com─ │ │ People who think they know everything really annoy those of us who │ know we don't. --- Bjarne Stroustrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iD8DBQFKnxH6f9E0noFvlzgRApqiAKC/xF4z1x0t7s+8kAsTVoSxYFRFmQCfaUcx 7F+QaH0Fdc9baW9Wcgl3swM= =ukVk -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 ?? Nope. There is no way of getting access to multiple Javascript threads from a web browser, unless you use some sort of extension like Google Gears or HTML5 web workers. Every part of the Javascript VM that your code can see is part of the same event loop. more over is the limit of 2 open http request apply on 2 diffrent modules running in diffrent iframes ?? Don't know about this one. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ People who think they know everything really annoy those of us who │ know we don't. --- Bjarne Stroustrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKnxH6f9E0noFvlzgRApqiAKC/xF4z1x0t7s+8kAsTVoSxYFRFmQCfaUcx 7F+QaH0Fdc9baW9Wcgl3swM= =ukVk -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
another thing about the http request limitation most browsers rejects more then 2 simultinus requests to a spacific url and i wondered i its aplays to 2 diffrent browser windows (diffrent process in new browsers) and if iframe acts as new web page maybe the limitation grows by 2 for each iframe On Sep 2, 5:05 pm, ben fenster fenster@gmail.com wrote: your answear is based on your knolage in js but i need an answear based on actual in depth knowlage in how browser work since each iframe act as an independed wep page and loaded sepertly then the containing page made me wonder about how its being done without a diffrent thread ? and if another thread is envolved in loading then maybe the new thread is also responsible on running the js code contained in the page of the iframe ? On Sep 2, 5:46 pm, David Given d...@cowlark.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 ?? Nope. There is no way of getting access to multiple Javascript threads from a web browser, unless you use some sort of extension like Google Gears or HTML5 web workers. Every part of the Javascript VM that your code can see is part of the same event loop. more over is the limit of 2 open http request apply on 2 diffrent modules running in diffrent iframes ?? Don't know about this one. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─http://www.cowlark.com─ │ │ People who think they know everything really annoy those of us who │ know we don't. --- Bjarne Stroustrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iD8DBQFKnxH6f9E0noFvlzgRApqiAKC/xF4z1x0t7s+8kAsTVoSxYFRFmQCfaUcx 7F+QaH0Fdc9baW9Wcgl3swM= =ukVk -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Iframe = multithreading ???
your answear is based on your knolage in js but i need an answear based on actual in depth knowlage in how browser work since each iframe act as an independed wep page and loaded sepertly then the containing page made me wonder about how its being done without a diffrent thread ? and if another thread is envolved in loading then maybe the new thread is also responsible on running the js code contained in the page of the iframe ? On Sep 2, 5:46 pm, David Given d...@cowlark.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 ?? Nope. There is no way of getting access to multiple Javascript threads from a web browser, unless you use some sort of extension like Google Gears or HTML5 web workers. Every part of the Javascript VM that your code can see is part of the same event loop. more over is the limit of 2 open http request apply on 2 diffrent modules running in diffrent iframes ?? Don't know about this one. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─http://www.cowlark.com─ │ │ People who think they know everything really annoy those of us who │ know we don't. --- Bjarne Stroustrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iD8DBQFKnxH6f9E0noFvlzgRApqiAKC/xF4z1x0t7s+8kAsTVoSxYFRFmQCfaUcx 7F+QaH0Fdc9baW9Wcgl3swM= =ukVk -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
