Weak Reference proposal

[Mark S. Miller]

On Fri, Feb 19, 2016 at 5:36 PM, John Lenz <concavelenz at gmail.com> wrote:

> The finalizer holdings, could itself could hold a reference to the
> weakrefernce correct?
>

The holdings can certainly strongly point to the weakref itself, yes. There
is no reason to think this is a mistake.

By contrast, though we cannot prevent the holdings from strongly pointing
to the target, this would almost certainly be a mistake. It would prevent
the finalization that would involve this holdings. See the four scenarios at

https://github.com/tc39/proposal-weakrefs/issues/5#issuecomment-185955167

If the weakref with these holdings is itself strongly reachable (scenarios
1 and 2) then this will also prevent the target from being collected. If
the holdings is strongly reachable (scenario 4) the target again cannot be
collected. If the weakref and the holdings are both not reachable (scenario
3), then they and the target can all be collected at the same time without
any finalization action involving that holdings. Other weakrefs onto target
(wr3a) can observe target disappear, and can have their own finalization
actions. These will still be triggered.

There is a possible controversy regarding scenario 2, for which I'll refer
you to the issue.


> On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble <tribble at e-dean.com> wrote:
>
>> Thanks for your comments.
>>
>> A practical answer to your question:  If you drop references to a
>> subsystem that internally uses weak references, the "finalization" it would
>> engage is just death throes. For example, if you drop an Xml parser, then
>> there's no reason to muck out it's internal cache since that's going to be
>> collected anyway. Thus, this variant is more expressive.
>>
>> It also breaks the retention properties of the system. In order to
>> require the executor to run, *something *has to point at it (and the
>> holdings) strongly. Otherwise for example the holdings and executor might
>> not be retained (and you couldn't run finalization). You can end up with
>> cycles of executors pointing at each other's targets such that neither can
>> ever be collected because the system is keeping them around strongly.
>>
>> On Thu, Feb 18, 2016 at 10:42 PM, John Lenz <concavelenz at gmail.com>
>> wrote:
>>
>>> This seems like a very solid proposal.  I like that the finalizers run
>>> on their own turn (it had to be that way in retrospect).
>>>
>>> I'm unclear about one thing: the reasoning for not running finalizers
>>> when weak-references them become unreferenced.  Did I misunderstand this?
>>> Doesn't this force he "hard" reference to also a soft reference "weak
>>> reference" to insure that finalizer run (such as closing a file, etc)?  If
>>> aren't concerned about non-memory resources is there any point to having
>>> holding at all?
>>>
>>>
>>>
>>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble <tribble at e-dean.com>
>>> wrote:
>>>
>>>> I have posted a stage 1 proposal for weak references in ES7 for your
>>>> perusal and feedback.
>>>>
>>>> https://github.com/tc39/proposal-weakrefs.git
>>>>
>>>> Thanks to Mark Miller and the authors of earlier proposals for help
>>>> with the document and content!  Finally thanks to a few intrepid early
>>>> reviewers for their edits, comments, and feedback.
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160219/9e2fea2f/attachment-0001.html>