Agreed that Object.freeze does not give you what you need. RiverTrail already needs a kind of collection that is transitively immutable by construction. They need this for safe data parallelism. But the reason they are safe for parallel access within a vat/worker is the same reason they would be safe to pass-by-sharing between vats/workers that share an address space. And between address spaces, including between machines, they would be passed by copy, but without any observable difference beyond performance. We should keep this in mind as we proceed on the RiverTrail work.
On Sun, Apr 21, 2013 at 3:49 PM, Sam Tobin-Hochstadt <[email protected]>wrote: > Then consider `Object.freeze(console)`. > > Fundamentally, frozen objects are not appropriate for prohibiting shared > state. > > Sam > > On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd <[email protected]> wrote: > > isn't typeof (console.log) "function" and not "object"? by object I > meant an > > Object object, not 'any arbitrary JS value'. I suppose the distinction is > > really blurry, and you would still have to deal with problems like the > > object's prototype chain containing callables... > > > > > > On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt <[email protected]> > > wrote: > >> > >> On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd <[email protected]> > wrote: > >> > if I called Object.freeze or Object.seal on a JS object would it > >> > actually be > >> > safe to pass it to another thread and let both threads use it without > >> > any > >> > locking or guards? > >> > >> No, it's not safe. Consider Object.freeze(console.log). > >> > >> Sam > > > > > > > > > > -- > > -kg > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
