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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
