Proxying built-ins (Was: [[Invoke]] and implicit method calls)

Mark S. Miller erights at
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) 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

#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> 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 will find child windows of it with
> name="name".  See**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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list