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
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>


More information about the es-discuss mailing list