Re: Weak callbacks?

2013/11/13 Mark S. Miller > * Weak consistency (I know, people hear "CAP" and give up too much) won, > which surprised some. > > Because Promises are asynchronous, even locally, the state of the world > when a promise-based request is made differs from the one in which the > request is received.

Re: Weak callbacks?

2013/11/11 Mark S. Miller > Much of the early Actors research > DEC SRC Network Objects > RMI > Original-E before I arrived at Electric Communities > Midori > Orleans > AmbientTalk > Cap'n Proto > While I'm honored to see AmbientTalk listed among these systems, I should note that, pertinent to t

RE: Weak callbacks?

Claus, that is not how ES6 promises work. (Or their predecessors in Q and elsewhere.) In essence, the "then" message sent to a promise is just one of many, and in particular it can't be pipelined. If you were to pipeline a "get" message, you wouldn't do so via the "then" mechanism. More on this

Re: Weak callbacks?

I mean the promises-unwrapping proposal that has now been accepted into ES6 and the DOM, and IIUC is being implemented by several browser makers. Let's call these JS Promises. The unwrapping means that there is forced recursive synchronization, doesn't it? When trying to work with nested promi

Re: Weak callbacks?

Boris Zbarsky wrote: On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The same thing that sites (e.g

Re: ECMAScript error sink (was: Weak callbacks?)

On Nov 13, 2013, at 7:58 AM, David Bruant wrote: > ... > The browser has window.onerror for historical reasons, Node.js introduced > Domains and Domain#intercept [1] for that reason IIUC. > Isn't it the sign that ECMAScript should have this feature built-in? > A global sink has something absurd

Re: ECMAScript error sink (was: Weak callbacks?)

On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining "unhandled

ECMAScript error sink (was: Weak callbacks?)

Le 13/11/2013 06:15, Boris Zbarsky a écrit : On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The sa

Re: Weak callbacks?

On Tue, Nov 12, 2013 at 8:07 PM, David Bruant wrote: > Le 12/11/2013 13:42, Kris Kowal a écrit : > > One of the concerns with promises is that they consume exceptions that >> may or may not be handled. > > ... > I understand the need to know when a promise has an unhandled error at > developme

Re: Weak callbacks?

On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The same thing that sites (e.g. Facebook) do with wi

Re: Weak callbacks?

Finding out at runtime (by doing a sanity check in the finalizer) is a way to catch bugs in the application that were not caught at compile/development time, so you can log/report them and go back and fix them. This is an incredibly useful facility since (generally speaking) promise libraries have

Re: Weak callbacks?

Le 12/11/2013 13:42, Kris Kowal a écrit : One of the concerns with promises is that they consume exceptions that may or may not be handled. I have been looking forward for WeakRef as one of the avenues available to mitigate this problem. A post-mortem finalizer would be able to surface an error

Re: Weak callbacks?

On Tue, Nov 12, 2013 at 6:19 PM, Allen Wirfs-Brock wrote: > > On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote: > > > > > > > Nevertheless, remember that I am not yet asking TC39 to standardize > distributed JS itself, and will not until we have some cowpaths. The ES7 > question is only regarding

Re: Weak callbacks?

On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote: > > > Nevertheless, remember that I am not yet asking TC39 to standardize > distributed JS itself, and will not until we have some cowpaths. The ES7 > question is only regarding the remaining necessary primitive to start these > paving effor

Re: Weak callbacks?

In summarizing the history, I held back from mentioning names because it is a long history and many people deserve thanks. Nevertheless, a few names stand out so much I can't talk about the history without thanking them: E. Dean Tribble Domenic Denicola Kris Kowal Tyler Close Without them, E-like

Re: Weak callbacks?

On Tue, Nov 12, 2013 at 4:16 PM, Brendan Eich wrote: > Mark S. Miller wrote: > >> >> > However, many clients will engage in honest GC to keep their >> requirements on >> > service memory low. Many services will not need to cut such >> clients off >> > because of excessive reso

Re: Weak callbacks?

I mean the promises-unwrapping proposal that has now been accepted into ES6 and the DOM, and IIUC is being implemented by several browser makers. Let's call these JS Promises. These descend from Promises/A+ which have a long and complicated history, but the major branches of that history all to bac

Re: Weak callbacks?

Mark S. Miller wrote: > However, many clients will engage in honest GC to keep their requirements on > service memory low. Many services will not need to cut such clients off > because of excessive resource demands. Perhaps, but they still need to cut off bad clients, an

Re: Weak callbacks?

On 11/12/13 2:01 PM, Matthew Robb wrote: Perhaps somewhere in the middle would work, something like a regular map but that also pays attention to the ref count changes of key and an author can hook in with a callback that effectively means "reached 1 ref". Consider this testcase: var elem =

Re: Weak callbacks?

Mark S. Miller wrote: Link please for the Stonebreaker point? Sorry, having a hard time finding it now. It was about the longer history since SQL was pioneered; also about NoSQL. On your other bullets, you're preaching to the choir. These are exactly the considerations that led to the E pro

Re: Re: Weak callbacks?

Just to be clear on my use case. I am not trying to build distributed objects. I am building an object management layer similar to what EOF/WebObjects was. The purpose is to expose in the client a graph of object for display and edition. The purpose of this is to simplify writing client side app

Re: Speculations on Erlang (was: Weak callbacks?)

Mark S. Miller wrote: I don't think it does in practice, any more than UNIX does. How does a UNIX admin (or the kernel) decide when to kill a process? Good question. How do they? Old-style Unix admin involves dedicating process seats, doing shallow supervision-tree-style management,

Re: Weak callbacks?

On Tue, Nov 12, 2013 at 10:49 AM, Brendan Eich wrote: > Mark S. Miller wrote: > >> Much of the early Actors research >> DEC SRC Network Objects >> RMI >> Original-E before I arrived at Electric Communities >> Midori >> Orleans >> AmbientTalk >> Cap'n Proto >> > > Mark (and Tom, cc'ed), please tak

Re: Weak callbacks?

One of the concerns with promises is that they consume exceptions that may or may not be handled. I have been looking forward for WeakRef as one of the avenues available to mitigate this problem. A post-mortem finalizer would be able to surface an error that was trapped by a promise or promises tha

Re: Weak callbacks?

On Tue, Nov 12, 2013 at 11:10 AM, Jason Orendorff wrote: > On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller > 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 crit

Re: Speculations on Erlang (was: Weak callbacks?)

On Tue, Nov 12, 2013 at 11:23 AM, Jason Orendorff wrote: > (factoring out this part of the conversation because it seems like a > bit of a sidetrack) > > Mark and me: > >> > Why do you believe manual deallocation decisions will be easier in > >> > distributed systems than they are locally? > >> >

Speculations on Erlang (was: Weak callbacks?)

(factoring out this part of the conversation because it seems like a bit of a sidetrack) Mark and me: >> > Why do you believe manual deallocation decisions will be easier in >> > distributed systems than they are locally? >> >> I don't. That's why I cited several examples of systems that require >

Re: Weak callbacks?

Le 12/11/2013 10:18, Pierre Frisch a écrit : Could I present another example where WeakRef are required. I am writing an object management layer similar to what exist in other language and systems. One of the requirement is uniquing so that each object exist only once in memory. Let say I retr

Re: Weak callbacks?

Matthew Robb wrote: With the introduction of custom elements I find myself more and more interested in script that is tightly coupled to DOM nodes but that can be safely spun down when that node is GC'd (not just lifecycle "removed"). This could be achieved by having a callback on weakmaps or

Re: Weak callbacks?

On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller 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 ma

Re: Weak callbacks?

With the introduction of custom elements I find myself more and more interested in script that is tightly coupled to DOM nodes but that can be safely spun down when that node is GC'd (not just lifecycle "removed"). This could be achieved by having a callback on weakmaps or some way to hook into the

Re: Weak callbacks?

Mark S. Miller wrote: Much of the early Actors research DEC SRC Network Objects RMI Original-E before I arrived at Electric Communities Midori Orleans AmbientTalk Cap'n Proto Mark (and Tom, cc'ed), please take this as sincere feedback from a fan -- I mean this in the best possible way: I rem

Re: Re: Weak callbacks?

Hi Pierre, as long as this use would not need inter-realm weakrefs to be weak, as seems likely, then I think it could live fine with the existing proposal for securing weakrefs. No need to tilt any balance away from security. On Tue, Nov 12, 2013 at 10:18 AM, Pierre Frisch wrote: > Could I prese

Re: Re: Weak callbacks?

Could I present another example where WeakRef are required. I am writing an object management layer similar to what exist in other language and systems. One of the requirement is uniquing so that each object exist only once in memory. Let say I retrieve a company and its employees and later ret

Re: Weak callbacks?

(parenthetical aside replying to a parenthetical aside! Mark S. Miller wrote: If anything, local manual deallocation should be easier, and these have already proven hard enough that people (except C++ and Rust programmers) have turned to local GC. /be)

Re: Weak callbacks?

On Mon, Nov 11, 2013 at 1:09 PM, Jason Orendorff wrote: > On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller > wrote: > > On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff < > jason.orendo...@gmail.com> > >> JS users do not want RPC systems where one process's memory usage > >> depends on getting pe

Re: Weak callbacks?

On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller wrote: > On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff >> JS users do not want RPC systems where one process's memory usage >> depends on getting per-object callbacks from an untrusted peer's GC >> implementation. > > Some will. I do. See

Re: Weak callbacks?

On 11/11/13 2:51 PM, Matthew Robb wrote: What I am suggesting would not be bound to a WeakRef rather to the WeakMap. So in my mind it seems like the WeakMap can maintain a strong ref to the values it stores (not the keys obviously) The whole point of a weakmap is that it does not maintain a str

Re: Weak callbacks?

What I am suggesting would not be bound to a WeakRef rather to the WeakMap. So in my mind it seems like the WeakMap can maintain a strong ref to the values it stores (not the keys obviously) and before the value get's removed from that WeakMap, fire off a notifier. On Mon, Nov 11, 2013 at 11:46 A

Re: Weak callbacks?

On 11/11/13 2:43 PM, Matthew Robb wrote: I haven't been able to read through all of this very thoroughly but I would like to inject that I have a use case right now for some sort of callback on a WeakMap that notifies AFTER the key has been GC'd but before the value has been released. Requiring

Re: Weak callbacks?

I haven't been able to read through all of this very thoroughly but I would like to inject that I have a use case right now for some sort of callback on a WeakMap that notifies AFTER the key has been GC'd but before the value has been released. If this already exists and I just can't locate it I am

Re: Weak callbacks?

On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff wrote: > On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller wrote: > (re: weakrefs and post-mortem finalization) > > They are needed for many other things, such as > > distributed acyclic garbage collection (as in adapting the CapTP ideas to > > distri

Re: Weak callbacks?

On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller wrote: (re: weakrefs and post-mortem finalization) > They are needed for many other things, such as > distributed acyclic garbage collection (as in adapting the CapTP ideas to > distributed JS). I'm not convinced acyclic distributed GC is a good thin

Re: Weak callbacks?

Hi David, there's a distributed race condition that's fixed by the use of importCount. Fixing it using post-mortem finalization creates a local race condition which is fixed by this test, not if the proxy is *still* alive, but if a new proxy has been installed as its reincarnation. For background,

Re: Weak callbacks?

Le 08/11/2013 20:35, Mark S. Miller a écrit : Please try -- such experiments are interesting. I am :-) But even if this experiment is successful, I hope and expect that we'll have weakrefs and post-mortem finalization in ES7. They are needed for many other things, such as distributed acyclic

Re: Weak callbacks?

The difference is that if the large cycle is only uncollected because the weak references haven't been zapped, in a low memory/out of memory situation, the runtime's collector can go through and zap all weak references. If I write an ES application and do my own cycle collection/weak reference zapp

Re: Weak callbacks?

On Nov 7, 2013, at 3:16 PM, Mark Miller wrote: > I agree. This is a good use for weakrefs without the need for finalization. > Thanks! > > > On Thu, Nov 7, 2013 at 3:12 PM, K. Gadd wrote: > The problem is that the cycles remain uncollectable for a very long period of > time, even though func

Re: Weak callbacks?

More tooling is great for developing new software in ES, but it does nothing to address use cases where existing software and algorithms can't be ported without Weak References. Perhaps enough research will allow us to arrive at some sort of general 'best practice' for replacing the use of weak ref

Re: Weak callbacks?

Please try -- such experiments are interesting. But even if this experiment is successful, I hope and expect that we'll have weakrefs and post-mortem finalization in ES7. They are needed for many other things, such as distributed acyclic garbage collection (as in adapting the CapTP ideas to distrib

Re: Weak callbacks?

Le 08/11/2013 17:09, Jason Orendorff a écrit : (As a bonus, the weirdness will happen in one implementation and not another, and you and your users will blame the implementation. So there will be pressure on implementers to reduce the nondeterminism by doing GC more frequently—which trades off ag

Re: Weak callbacks?

On Thu, Nov 7, 2013 at 6:40 PM, K. Gadd wrote: > To contrive a scenario that might illustrate where event listeners aren't > necessarily enough: Let's say I have an entity system for a game that is > modelling thousands of independent entities that interact. In this system, > entity A might decide

Re: Weak callbacks?

On Nov 8, 2013 1:46 AM, "Mark Miller" wrote: > > On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen wrote: >> >> It seems that every (real) usecase for weakRefs, weakMaps and weakSets is to implement a weak event listener system. > > > Not true. Even silly. Sorry, I may have worded that a bit stro

Re: Weak callbacks?

On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen wrote: > It seems that every (real) usecase for weakRefs, weakMaps and weakSets is > to implement a weak event listener system. > Not true. Even silly. > Unfortunately weak event listeners cannot be implemented with the current > weakSet/weakMap

Re: Weak callbacks?

Please reread my example, events are a part of it but it is not exclusively about events. My example explicitly demonstrates the modes holding references in *both* directions, and only one of them is an event listener. You're correct that weak event listeners solve some of the problems that are us

Re: Weak callbacks?

On Thu, Nov 7, 2013 at 11:42 PM, K. Gadd wrote: > I'll try and restate an example I used before. > > Let's say you're building a somewhat simple tab-based application, where > each tab represents a different 'mode'. In this case, you need a higher > level coordinating object that manages the tab

Re: Weak callbacks?

Would someone be interested in putting together a small code example, before and after weak refs, illustrating this situation? I have a feeling this conversation will be referenced in many future threads, and the added clarity of code would be greatly helpful. On 7 Nov 2013, at 18:16, "Mark Mil

Re: Weak callbacks?

I agree. This is a good use for weakrefs without the need for finalization. Thanks! On Thu, Nov 7, 2013 at 3:12 PM, K. Gadd wrote: > The problem is that the cycles remain uncollectable for a very long period > of time, even though functionally the references don't need to be strong. > > > On Th

Re: Weak callbacks?

The problem is that the cycles remain uncollectable for a very long period of time, even though functionally the references don't need to be strong. On Thu, Nov 7, 2013 at 3:10 PM, David Bruant wrote: > Le 07/11/2013 22:46, K. Gadd a écrit : > > That's the sort of obstacle that factors into a

Re: Weak callbacks?

Le 07/11/2013 22:46, K. Gadd a écrit : That's the sort of obstacle that factors into a developer's choice of language and toolset. I've seen this particular concern with ES crop up in the past on real projects, and I've seen firsthand how difficult it is to avoid uncollectable cycles in a langu

Re: Weak callbacks?

Ah, sorry, I misread your description of the relationships. Yeah, that would be hard to do with WeakMaps. On Thu Nov 07 2013 at 3:02:02 PM, K. Gadd wrote: > I am not aware of any way to implement my described scenario using > WeakMaps without having the same cycle collection issues. I haven't se

Re: Weak callbacks?

I am not aware of any way to implement my described scenario using WeakMaps without having the same cycle collection issues. I haven't seen any examples of WeakMap used for this in the wild either. On Thu, Nov 7, 2013 at 2:48 PM, felix lee wrote: > That example looks to me like it could be imple

Re: Weak callbacks?

That example looks to me like it could be implemented with WeakMap instead of WeakRef. Am I missing something? On Thu Nov 07 2013 at 2:43:45 PM, K. Gadd wrote: > I'll try and restate an example I used before. > > Let's say you're building a somewhat simple tab-based application, where > each tab

Re: Weak callbacks?

I'll try and restate an example I used before. Let's say you're building a somewhat simple tab-based application, where each tab represents a different 'mode'. In this case, you need a higher level coordinating object that manages the tab bar, and it needs to own references to all of the active mo

Re: Weak callbacks?

Could you give an example, hopefully simple, of such a problem you can solve better with GC + weakmaps + weakrefs but without finalization, vs just GC + weakmaps ? Thanks. On Thu, Nov 7, 2013 at 1:46 PM, K. Gadd wrote: > When I talk about the importance of weak references I am *not* talking > a

Re: Weak callbacks?

When I talk about the importance of weak references I am *not* talking about the importance of finalization for managing native/remote resources; that's an important consideration but it's a separate one. When I talk about why weak references are important, I mean for the purposes of building large

Re: Weak callbacks?

On 11/06/2013 07:37 PM, K. Gadd wrote: > Generally speaking, all the discussions on this list about WRs so far have > not suggested that there is any way to introduce WeakRefs without making GC > behavior observable in some fashion. WeakRefs functionally make GC > observable because when you try to

Re: Weak callbacks?

On Wed, Nov 6, 2013 at 7:37 PM, K. Gadd wrote: > Generally speaking, all the discussions on this list about WRs so far have > not suggested that there is any way to introduce WeakRefs without making GC > behavior observable in some fashion. WeakRefs functionally make GC > observable because when

Re: Weak callbacks?

Generally speaking, all the discussions on this list about WRs so far have not suggested that there is any way to introduce WeakRefs without making GC behavior observable in some fashion. WeakRefs functionally make GC observable because when you try to get at the target of the weakref, you either g

Re: Weak callbacks?

The handler gets notified by the garbage collector. There are two conventional ways for this to be specific to the object being gc'ed. 1) Just create a unique handler for each weakref registration. If *this* handler gets notified, then it knows that the object it was about has been gc'ed. 2) (The

Re: Weak callbacks?

On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt wrote: > On Nov 6, 2013, at 3:14 PM, Rick Waldron wrote: > > > On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola < > dome...@domenicdenicola.com> wrote: > >> Thanks Mark for the education, especially on the pre- vs. post-morterm >> finalization distinct

Re: Weak callbacks?

On Nov 6, 2013, at 3:14 PM, Rick Waldron wrote: > > > > On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola > wrote: > Thanks Mark for the education, especially on the pre- vs. post-morterm > finalization distinction. I don't think I was specifically advocating for > pre-mortem in my OP, sinc

Re: Weak callbacks?

On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > Thanks Mark for the education, especially on the pre- vs. post-morterm > finalization distinction. I don't think I was specifically advocating for > pre-mortem in my OP, since I didn't really understand the di

Re: Weak callbacks?

First, I'll cheekily answer what you asked instead of what you meant to ask: One of the important properties of post-mortem finalization is that it is *not* triggered by the collection of the weakref itself, and is not triggered if the weakref is co-condemned with the object it points at. On your

Re: Weak callbacks?

Are these callbacks triggered for the garbage collection of any object or just weakrefs? They could be useful to help track down memory leaks, although the tooling in Chrome is quite good for that. On Wed, Nov 6, 2013 at 7:15 PM, Domenic Denicola wrote: > Thanks Mark for the education, especially

Re: Weak callbacks?

It is part of the WeakRefs proposal. Always has been. On Wed, Nov 6, 2013 at 11:15 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > Thanks Mark for the education, especially on the pre- vs. post-morterm > finalization distinction. I don't think I was specifically advocating for > pre

RE: Weak callbacks?

Thanks Mark for the education, especially on the pre- vs. post-morterm finalization distinction. I don't think I was specifically advocating for pre-mortem in my OP, since I didn't really understand the difference :P. Post-mortem finalization sounds quite reasonable. What do people think of int

Re: Weak callbacks?

On Wed, Nov 6, 2013 at 10:49 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > Over lunch I was discussing ES6 and ES7 features with some developers > doing JavaScript crypto, and they mentioned an interest in not only weak > references, but weak callbacks. That is, a no

Weak callbacks?

Over lunch I was discussing ES6 and ES7 features with some developers doing JavaScript crypto, and they mentioned an interest in not only weak references, but weak callbacks. That is, a notification when your object gets garbage collected, similar (I think) to what V8 has with its `MakeWeak