std.container.BinaryHeap + refCounted = WTF???

[Steven Schveighoffer]

On Tue, 16 Nov 2010 15:47:07 -0500, dsimcha <dsimcha at yahoo.com> 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