On Wed, Nov 29, 2017, 19:19 /#!/JoePea <j...@trusktr.io> wrote:
> Hello all, I'm posting here because I'm thinking about how not to leak
> memory, and wondering if I am.
>
> Suppose I have an object that is cleaned up (GC'd), and that object's
> constructor (for example) ran an anonymous function that listened to a
> Promise. For exampel:
>
> ```js
> class Foo {
> constructor() {
> // ...
> this.somePromise.then(() => {console.log('this will never fire if this
> object is GC'd')})
> }
> }
> ```
>
> Suppose that if this object gets collected, then it means that there is
> nothing in my application that will ever be able to resolve this object's
> `somePromise`.
>
> Does the engine also garbage collect `somePromise` and the attached
> handler?
>
Yes, provided nothing else is referencing it.
> Now, what if `somePromise` is referenced outside of this object by some
> other code waiting on yet another promise who's handler will resolve this
> object's `somePromise`? Does this prevent the object from being GC'd? Or is
> the object GC'd, but `somePromise` is not and the above console.log should
> still fire at some point (or memory will be leaked)?
>
The object itself is GC'd independently of its members absent a circular
reference.
A thing to keep in mind is that a promise could still be referenced by its
resolving functions, even if the promise itself is no longer referenced by
ECMAScript code. This keeps the promise state alive, so it can still fire
(otherwise, you'd have observable GC). So, in this example, things will
still fire regardless:
```js
function foo() {
let p = new Promise(resolve => {
setTimeout(resolve, 1000)
})
p.then(() => {
console.log("This still fires")
})
// `p` is no longer referenced by the
// calling function, but it's still referenced
// by the enqueued `setTimeout` task, so
// it can't be collected
}
foo()
```
>
> */#!/*JoePea
>
> On Thu, Jan 12, 2017 at 1:12 PM, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> And that's why we're waiting on the next meeting to happen with notes
>> posted, so we can figure out what to do next. It's likely to get discussed,
>> especially considering the current situation and pressing need for it.
>>
>> On Thu, Jan 12, 2017, 13:27 Jordan Harband <ljh...@gmail.com> wrote:
>>
>>> The Cancellable Promises proposal itself is currently withdrawn, but
>>> don't forget that all of the previous discussion on cancellation in
>>> promises led to that proposal.
>>>
>>> It would be shortsighted to pretend they don't exist, or that the spec
>>> proposal won't matter forever to any other cancellation proposal, and doing
>>> so won't help any alternative proposal.
>>>
>>> On Thu, Jan 12, 2017 at 7:44 AM, Jan-Ivar Bruaroey <j...@mozilla.com>
>>> wrote:
>>>
>>> Cancellable promises is dead. Please don't hijack this thread discussing
>>> them.
>>>
>>> Thanks,
>>>
>>> .: Jan-Ivar :.
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
