Proxying built-ins (Was: [[Invoke]] and implicit method calls)
Mark S. Miller
erights at google.com
Thu Sep 26 08:55:28 PDT 2013
I think we need to distinguish two senses of process when we ask this
a) address space separation in the implementation
#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
#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?
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss