domenic at domenicdenicola.com (2013-11-17T17:58:09.929Z)
On Tue, Nov 12, 2013 at 11:10 AM, Jason Orendorff <jason.orendorff at gmail.com> wrote: > I don't see anything in Cap'n Proto that is related to weak references > or GC. At the protocol level, it seems capabilities are explicitly > dereferenced. I assume you meant "dropped", "decremented", "deleted", or "destroyed" rather that "dereferenced"? If so... At the CapTP level they are as well. Likewise within the implementation of any GC system, whether local or remote. https://github.com/kentonv/capnproto/blob/master/c++/src/capnp/rpc.capnp http://www.erights.org/elib/distrib/captp/dagc.html
On Tue, Nov 12, 2013 at 11:10 AM, Jason Orendorff <jason.orendorff at gmail.com > wrote: > On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller <erights at google.com> > wrote: > > Much of the early Actors research > > DEC SRC Network Objects > > RMI > > Original-E before I arrived at Electric Communities > > [...] > > Sure. I can only echo Brendan's critique. None of the projects you > listed are in JS, most are research, a few maybe shouldn't be in the > list because we don't actually know anything about them, and a couple > I couldn't find online. > > The distributed object systems that saw widespread use were DCOM, > CORBA, and Java RMI. They all happened in the 1990's, they were widely > used for a little while, and then they vanished. They were considered > painful to use. (Of course, none of them were E.) > > I'm not opposed to people trying to bring the distributed objects idea > back. If it stuck, it would be rather glorious. But until it's been > proven, it just isn't a use case that should drive the evolution of > JS. > > That's my only point in this thread. > > > Much of the early Actors research did cyclic GC as well, but this early > > distribibuted GC work notably violated the general Actors assumption of > > mutual suspicion. > > Right, implementing full DGC (with cycles) in untrusted JS isn't in the > cards. > > > Cap'n Proto is designed primarily for the local C++ bindings. It has the > > distributed acyclic GC logic I explain, but typically driven by local > manual > > deallocation rather than local GC and finalization. > > I don't see anything in Cap'n Proto that is related to weak references > or GC. At the protocol level, it seems capabilities are explicitly > dereferenced. > I assume you meant "dropped", "decremented", "deleted", or "destroyed" rather that "dereferenced"? If so... At the CapTP level they are as well. Likewise within the implementation of any GC system, whether local or remote. https://github.com/kentonv/capnproto/blob/master/c++/src/capnp/rpc.capnp http://www.erights.org/elib/distrib/captp/dagc.html > It is possible for a peer to hook up with a GC to manage those > capability lifetimes on one side, but then, there are also other > possible designs that wouldn't require weakrefs and would tend to > provide more timely cleanup, e.g. leases, resource pools, or FIFO > allocation (like the C++ bindings --- that API is a whole lot better > than explicit malloc/free). There are also alternatives at the > protocol level. > > > What "abundance of widely used alternative designs" do you mean? > > Alternatives to "distributed objects"-based designs (CORBA, DCOM, Java > RMI, E) for distributed computing. > > -j > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131112/d173e5fe/attachment.html>