Java syntax question.
https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html -- 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 ???
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 ???
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: Java syntax question.
On Thursday, September 14, 2017 at 5:48:26 PM UTC+2, Ananchai Srirochanakul wrote: > > Thank you so much. I understand it now. > > On Thursday, September 14, 2017 at 12:46:58 AM UTC-7, Jens wrote: >> >> https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html > > > BTW, the *only* special syntax in GWT is JSNI [1] (uses the standard Java 'native' keyword, and a standard Java comment, the comment content is special though), but JSNI is deprecated in favor of JsInterop [2] anyway. Everything else is "just Java" (and actually, even JSNI is "just Java": a Java compiler won't choke on it, it'll only break if you attempt to run it in a JVM) [1] http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html [2] http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJsInterop.html -- 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.
