Mark S. Miller <mailto:[email protected]>
September 26, 2013 8:55 AM
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.
IE9 and above use multiple processes, and I'm told sometimes window.open
does a DCOM thing and everything's racy after that: setting win.name,
win.document.open/write, etc.
I'm sure MS folks will correct me if I'm wrong, but I can believe this
is "compatible enough".
#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.
Distributed GC is harder still because of network partitioning and
multiple machine failure scenarios, but you're right that the cycle
collection problem arises with multi-process GC, as with
multi-language-VM-heap and with distributed multi-machine.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
