Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote: I don't think it's correct to say that SharedWorkers are not useful and we need a SharedScript instead. They are different things and can address different use cases. For example, SharedWorker is great to make sure there is only one 'app instance' running - exactly because it is shared inter-process, it can be used as a inter-process synchronization primitive to control how many app instances are opened. SharedScript is a container for data and code shared between pages that comprise a web application and normally run in the same process. As in native apps, whether or not multiple instances of the app can run at the same time depends on the author of the app, and can be done either way. Multi-process browsers are bringing more complexity (and benefits). Not all technical issueshttp://www.chromium.org/developers/design-documents/process-modelsare completely resolved in Chrome's implementation, and we might need (or not) some mechanism of saying that a bunch of pages form an application and should share a process. Right now, it's unclear if such mechanism even needed though. I agreed with you to remove the implementation details from the doc because indeed they do not belong there. Not that they are not existing. For example, the fact that in Chrome SharedWorkers are indeed inter-process theoretically could be different. WebWorkers spec does not specify where and how to look for instances of SharedWorkers, although it implies some useful degree of sharing. The fact that in Chrome they are shared across all processes is a detail of Chrome implementation. The Worker implementation behaviour is not really relevant to this conversation. The issue is whether a browser implements a spec in a correct manner, that's why implementation is not described. A worker for instance may be per thread, per process, or may not even represent a separate machine thread and could be implemented by in software just running each task in sequence (assuming a sufficiently careful implementation, etc, etc). The issue we're discussing however was what Darin bought up -- should a multiprocess browser be allowed to have multiple distinct instances of the same Global/SharedScript? the answer is clearly no (and that concept has been removed from the spec); Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). Cheers, -Darin The resultant implication is that a Shared or Global script would have not need to be shared at all and each page could have it's own copy -- effectively degenerating to a glorified iframe. I would consider it to be a warning sign of potential badness in a spec if behaviour was being defined by perceived difficulty in implementing a feature, rather than on the desired end user behaviour. In general I feel a spec should always favour complexity of implementation over complexity in use, after all if a feature is hard to implement it still only needs to be implemented a relatively small number of times (basically once per browser/engine) pushing the complexity on to end developers however then means thousands (millions?) of developers have to implement the same code and deal with the same complexity over and over again. Obviously if there's an option to avoid any complexity that would be best, but i suspect that's unlikely to exist :-D --Oliver Dmitry On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen gga...@apple.com wrote: Just a note: In Chrome, a SharedWorker is reachable from any WebKit process, whereas a SharedScript would only be reachable within a WebKit process. This is an interesting distinction, and I can imagine some use cases
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. This is an aside that concerns the general point above, not GlobalScript etc. specifically. I agree that in general we should push complexity towards the UA vendor and away from the web author, but your statement is too sweeping. It is certainly relevant to consider the concept of multiprocess browsers when designing APIs. Failing to take that into account at all can lead to APIs which make process separation outright impossible. It's one thing to make implementation somewhat trickier for UA vendors, it's another thing entirely to completely eliminate whole categories of browser architectures in the name of developer simplicity. To give an example of poor foresight in a spec from the past, synchronous XHR is convenient for developers in certain circumstances, but I think all implementors recognize that it was a mistake to specify and we'd be better off without it. For a ridiculous hypothetical example, we wouldn't spec an API that required UAs to solve the halting problem. Developer need and convenience should certainly be the prime motivator of APIs, but not the only motivator. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage The spec was co-written by real world users (gmail engineers). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage The spec was co-written by real world users (gmail engineers). Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. Charlie Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 6:31 PM, Oliver Hunt oli...@apple.com wrote: Has anyone really sat down and compared the use cases given in the spec to the behaviour of users? eg. to see if the model you're talking about would actually provide any real benefit in real world usage The spec was co-written by real world users (gmail engineers). Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared. The end user benefit is lower latency and resource usage. If you click the link in gmail to tear off a chat window or compose email window there's (very) user noticeable latency. Some of this we can continue to improve with browsers, but it's not easy and it will definitely be a while before an app like gmail can be loaded in 100ish ms (so it's not perceivable). And some (resource sharing) is nearly impossible without help from the app. On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis cr...@chromium.org wrote: The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. The main purpose of SharedScript is to make web apps more single threaded (and thus able to share more state). Besides the whole site crashing when one tab of it crashes, I don't really see any problem with having the whole app in the same processthat's essentially what's being asked of us. If we're only targeting opening new windows via script, then there's really no reason to do SharedScript since the windows can already access each other. You can even do clever things so that children of children still can communicate even if one of the middle nodes gets closed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis cr...@chromium.org wrote: On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt oli...@apple.com wrote: On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: Sorry, I think you misunderstand. The way Chrome processes are divided is an implementation detail, but it is an important one. I think it is folly to ignore it when designing web APIs. We'll likely *never* implement APIs that involve cross-process, synchronous script evaluation. We have some experience with that in supporting plugins, and I can tell you that I do not favor it: not just because of implementation complexity but also because of the performance impact it entails. It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. The issue being that in regular day to day use such a browser could end up producing behaviour inconsistent with behaviour that of browsers that actually did provide a single shared context -- in effect all users of Global/SharedScript would have to assume that their Global/SharedScript context was not in fact shared. This is true, but I don't think it is a big deal. Processes are roughly divided up into browsing units. You start a new browsing unit by opening a new tab and navigating it. By doing so, you are creating a separate world that cannot see other worlds. SharedWorkers (as well as cookies and other storage mechanisms) provide a bridge between these worlds, but window.open and SharedScripts do not (b/c of the script connection they imply). I have a (simple) question: If Global/SharedScript is not guaranteed to be either Global or Shared, what is it trying to accomplish? It's not possible for any developer to use them for shared state as they can't guarantee that a normal user, doing normal things, is not going to end up with distinct instances of this shared state. Please look at the use cases in the spec. They're pretty much all an optimization to cut down on resource utilization and load times by sharing more state. As a side note, I would expect that many SharedScript users would also use SharedWorkers for a lot of the non-UI logic including storage and network. Also note that the possibility of having multiple SharedScript instances within one browser is pretty much the same as the possibility of the user having multiple browsers open on the same computer. The point i was getting at is that unlike the typical way to get this situation (running multiple browsers) is not a common end user behaviour, but Chrome's model makes it very easy -- as far as I am aware if I open two windows independently and navigate both to example.com i will end up with two processes, thus ending up with two instances of the same SharedScript. I actually just did a quick test, and I am unsure how I can actually open two windows in such a way that Chrome would end up using a single SharedScript instance -- both new window and new tab result in separate processes, the only logical case that would allow multiple windows to end up sharing an instance (and thus gaining any benefit at all from this feature) would be by opening a window from an original source page, in which case an invisible iframe could trivially be passed around, and has all of the advantages of SharedScript, none of the disadvantages, and works in all existing browsers. The usage of SharedScript is a strong hint to the browser that future tabs for that origin should be opened in the same process. With such a heuristic, you only run into trouble when a particular origin doesn't immediately use the SharedScript and a user opens up another tab in the mean time. This could be mitigated by the browser saving which origins use SharedScript somewhere. [from the right email address] Just my two cents, but I don't think the browser's process model should change based on a web site's use of SharedScript. This would end up causing all of the instances of a given web site to share a process, which can have bad implications for responsiveness. (Basically, it eliminates most of the benefits of having a multi-process browser if the user visits a lot of pages from the same site.) I haven't been following the SharedScript discussion closely enough, but I was under the impression that it was mainly targeted at pages opened directly from existing pages. If the user creates separate windows and navigates them to the same site independently, I would argue that those should not share the same SharedScript. Charlie +1 Oliver, please re-review the use cases in the document. You'll
Re: [webkit-dev] SharedScript/Worker and multiprocess browsers
On Mon, Nov 30, 2009 at 5:45 PM, Peter Kasting pkast...@google.com wrote: On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt oli...@apple.com wrote: It is wrong to design an API based on architectural decisions of your existing browser -- you should be making decisions based on what the developers actually need. Being hard for the browser to implement is a secondary concern next to being hard for the end developer to use. This is an aside that concerns the general point above, not GlobalScript etc. specifically. I agree that in general we should push complexity towards the UA vendor and away from the web author, but your statement is too sweeping. It is certainly relevant to consider the concept of multiprocess browsers when designing APIs. Failing to take that into account at all can lead to APIs which make process separation outright impossible. It's one thing to make implementation somewhat trickier for UA vendors, it's another thing entirely to completely eliminate whole categories of browser architectures in the name of developer simplicity. To give an example of poor foresight in a spec from the past, synchronous XHR is convenient for developers in certain circumstances, but I think all implementors recognize that it was a mistake to specify and we'd be better off without it. For a ridiculous hypothetical example, we wouldn't spec an API that required UAs to solve the halting problem. Developer need and convenience should certainly be the prime motivator of APIs, but not the only motivator. PK +1 Being hard for the browser to implement is a secondary concern ^^^ Oliver, you are ignoring my assertion that it is not just about simplicity of implementation but also about the poor performance of the result. You negate much of the performance benefits of a multi-threaded architecture if you force the threads to run interlocked (required to enforce run-to-completion semantics). -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
