> Sorry for not replying, I've had some personal issues recently that have > taken up all of my time. Your suggestion seemed workable for solving the > dereferencing issue, but leaving the destroyed objects in an invalid state > seems likely to cause weird bugs. And the objects can't safely be reset to > their initial state (ala. clear) after destruction for concurrency reasons. > So I'm not sure it will really help all that much in practice. It wouldn't > be a tremendous amount of work to try this out though. On the druntime-list, it was also pointed out that the assumption that related objects are collected either in the same run or in reference-order are not true for all GC-types, I.E. not for incremental GC:s. Therefore it seems like a bad semantic to impose on the GC, in case someone wants other GC:s some day.
>> The problem I've encountered in D, is that support for complementary >> predictable allocation schemes which could alleviate some of the >> problems (i.e. reference-counting and tree-allocation), is quite weak. >> By weak, I mean undocumented and no supporting framework from the >> stdlib. In a perfect world, this could even work hand-in-hand with the >> GC, such that references to refcounted-object could be voided from the >> destruction of the reference-counted object. > There's been some talk of doing this, but other things have had priority. > >> Is this a discussion that should be held in Phobos/Tango, druntime, or >> on this list? > The druntime list would be most appropriate, but it has very few members > (partially because so few people are interested in this level of code, I > suspect). The most expedient solution would be to just write the code and > submit a patch for evaluation. > FYI: I don't have access to build-env for D2/druntime, but I've created an implementation for RefCounting for Tango, in http://www.dsource.org/projects/tango/ticket/2024. It might be of interest to port to druntime, with the mentioned D2-improvements to SmartRef.
