On Wed, 06 Oct 2010 16:19:45 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 10/6/10 14:09 CDT, Michel Fortin wrote:
On 2010-10-06 12:34:54 -0400, Andrei Alexandrescu
<[email protected]> said:
2. It would force certain types (such as BigInt) that allocate
resources and have value semantics to resort to reference counting.
Also, before asking for more reference counting, perhaps you should
check that bug and find a nice way to do reference counting correctly
with no race conditions (unlike what's done in Phobos currently).
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>
I'm not sure the bug report is valid, but I agree it's a matter to look
into.
It is valid. When you use GC-allocated memory in a destructor, it's bad
news. And structs that are members of classes can have their destructors
called from the GC.
The most problematic thing with reference-counted memory is that the GC
can call your struct's destructor from any thread which can cause
low-level races if the reference counter isn't manipulated with atomic
operations. And atomic operations slow things down, are you sure you
want to force this in BigInt?
The GC shouldn't be able to destroy things naively concurrently with
other threads. Currently all threads are frozen; I'm not sure whether a
frozen thread commits its writes, so that needs to be verified.
I think Michel is right. Let's say thread A is copying a File struct to
the stack, and is on this line:
this(this)
{
if (!p) return;
assert(p.refs);
++p.refs;
}
And thread B is allocating memory. This triggers a GC collection cycle,
and in the heap is a class object which contains the same File struct as a
member. That File's destructor is called, and
--refs is called. Note that the object being destroyed does not have to
be shared. This is a classic race.
-Steve
