domenic at domenicdenicola.com (2013-10-01T21:00:27.208Z)
I think we need to distinguish two senses of process when we ask this question: a) address space separation in the implementation b) concurrency b) would be a breaking semantic change, so I'm going to write that off here. Feel free to start a separate thread on public-script-coord if you like about whether this breaking change might be possible, but I'm skeptical. a) without b) might make use of OS processes in the implementation, since most OSes only provide separate address spaces to separate processes. But from a scheduling perspective, a group of address spaces can function as a single process by adopting the discipline that at most one is active at a time. A sync IPC makes the caller inactive and the callee active. It simulates exactly the locus of activity we have now in a single process single thread implementation. So the a) question in isolation really does reduce to the membrane question. Since no object references ever directly cross a membrane boundary implementing a realm boundary, the two sides of a membrane can be connected by only a bit channel with no loss of *observable* functionality. However, we'd lose the easy GC of cross compartment cycles we get right now by building in-address-space membranes using proxies and weakmaps. Cross-address-space GC is essentially the same problem as distributed GC, which is a big topic in itself.
I think we need to distinguish two senses of process when we ask this question: a) address space separation in the implementation b) concurrency #b would be a breaking semantic change, so I'm going to write that off here. Feel free to start a separate thread on public-script-coord if you like about whether this breaking change might be possible, but I'm skeptical. #a without #b might make use of OS processes in the implementation, since most OSes only provide separate address spaces to separate processes. But from a scheduling perspective, a group of address spaces can function as a single process by adopting the discipline that at most one is active at a time. A sync IPC makes the caller inactive and the callee active. It simulates exactly the locus of activity we have now in a single process single thread implementation. So the #a question in isolation really does reduce to the membrane question. Since no object references ever directly cross a membrane boundary implementing a realm boundary, the two sides of a membrane can be connected by only a bit channel with no loss of *observable* functionality. However, we'd lose the easy GC of cross compartment cycles we get right now by building in-address-space membranes using proxies and weakmaps. Cross-address-space GC is essentially the same problem as distributed GC, which is a big topic in itself. On Thu, Sep 26, 2013 at 8:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 9/26/13 10:45 AM, David Bruant wrote: > >> Formulated differently: does the web has requirements making such >> process isolation impossible? >> > > Unclear. > > The web has a requirement that if I have a pointer to a cross-origin > window "win" then doing win.name will find child windows of it with > name="name". See https://bugzilla.mozilla.org/**show_bug.cgi?id=916939<https://bugzilla.mozilla.org/show_bug.cgi?id=916939>for what happened when we tried to disallow this in Firefox. > > Now this could be implemented by having "win" be a cross-process proxy and > having the get be a blocking RPC call that returns another cross-process > proxy... maybe. Deadlock hazards abound. > > -Boris > > ______________________________**_________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/39b8d148/attachment-0001.html>