Weak Reference proposal

[John Lenz]

Right, I was suggesting that having the "holdings" hold the weakref itself
would be a means of by-passing the "don't run this finalizer if I forget
about this weakref" here. So it would still be useful to collect non-memory
resources, assuming you can live with the laziness inherent in GC/weakref
collection.

On Fri, Feb 19, 2016 at 5:51 PM, Mark S. Miller <erights at google.com> wrote:

> 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/20160220/f5d849f8/attachment.html>