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 <[email protected]> wrote: > On Fri, Feb 19, 2016 at 5:36 PM, John Lenz <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
