Sean Kelly wrote: > Ulrik Mikaelsson Wrote: > >> > I have posted about this problem several times. Never got any replies. >> > I think memory management is D's "elephant in the room" in this regard. >> I'm sorry to agree. I recently brought up this general question in a >> thread called "Mixing GC and non-GC in D." in both druntime and here. >> Only got one answer each in both druntime and this group. The problem >> basically, from all I've read about GC:s in general and the D GC in >> particular, is the problem of non-deterministic collection, both when >> and more importantly IF the object will ever be collected. This makes >> the GC unsuitable for "expensive" resources, such as file descriptors, >> or very big chunks of memory. > > 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. > >> 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.
Acctually I think one reason for low intrest on the druntime list is that people simply have not heard of it. I for one hasn't. I personally think more people would read it if it was just another news group on the digitalmars server. There might be other benefits for doing it the current way ofcurse.