On Tue, 16 Nov 2010 15:47:07 -0500, dsimcha <[email protected]> wrote:
I'm trying to use BinaryHeap in a multithreaded programming using
std.parallelism/parallelfuture. I kept getting ridiculous segfaults and
stuff, and when I looked into it in a debugger, I realized the crashes
had to
do with reference counting, probably caused by this line in BinaryHeap:
private RefCounted!(Tuple!(Store, "_store", size_t, "_length"),
RefCountedAutoInitialize.no) _payload;
Why the heck are the payload and the length being stored in such a weird
way?
IMHO BinaryHeap shouldn't use reference counting unless Store does.
More
generally, anything that uses reference counting, especially where
unexpected,
should come with a very strong warning in its ddoc so that people are
aware of
the hidden caveats, like copying it using memcpy() and sharing it across
threads.
I think in general containers don't work across multiple threads unless
specifically designed to do that.
dcollections containers would probably all fail if you tried to use them
from multiple threads.
That being said, I'm not a huge fan of reference counting period.
Containers have no business being reference counted anyways, since their
resource is memory, and should be handled by the GC. This doesn't mean
pieces of it shouldn't be reference counted or allocated via malloc or
whatever, but the object itself's lifetime should be managed by the GC
IMO. Not coincidentally, this is how dcollections is set up.
-Steve
