On Tuesday, 24 February 2015 at 20:35:04 UTC, Walter Bright wrote:
>> Only safe way to do this is to C malloc/free the count. And yes, at that point,
>> you need atomics.
>
> No, RCArray is not intended for shared access between threads.
>
> Shared containers and local containers are different enough that they merit being different types with different implementations altogether. Trying to just slap 'shared' on a container isn't going to work.

Maybe we want to fix the GC, exceptions and delegates or disable them in @safe code because they all cause implicit sharing.

On 2/24/2015 2:34 PM, deadalnix wrote:
> Maybe we want to fix the GC, exceptions and delegates or disable them in @safe
> code because they all cause implicit sharing.

Andrei already filed a bug report on the GC issue. If there aren't bug reports on the other two, file them.

On 2/24/2015 2:27 PM, deadalnix wrote:
> This may not be @safe depending on the type of E.

The code is a template, and so relies on inference.


> Also, this do not really solve the garbage problem

Steven pointed out the correct fix for that.


> Also, there are no way to ensure that the array is going to be bound to one
> thread, even without shared (exception, delegate, destructor, pure return). You
> need at least atomic increment and/or decrement.

No. The correct solution is to fix any cases of implicit sharing. If they don't have bugzilla issues, file them.


> I have to admit, that is pretty cool. But it is only gonna work with value types.

I don't see that limitation at all.


> You need bound check: end <= start <= array.length

See the antecedent:

"More could be done:
[...]
5. bounds checking"

On Wednesday, 25 February 2015 at 00:13:03 UTC, Walter Bright wrote:
> On 2/24/2015 2:34 PM, deadalnix wrote:
>> Maybe we want to fix the GC, exceptions and delegates or disable them in @safe
>> code because they all cause implicit sharing.
>
> Andrei already filed a bug report on the GC issue. If there aren't bug reports on the other two, file them.

Well I filled a bug on the delegate one ~2 years ago, and the 2 others are features, not bugs, as far as I know.

On 2/24/2015 4:32 PM, deadalnix wrote:
> On Wednesday, 25 February 2015 at 00:13:03 UTC, Walter Bright wrote:
>> On 2/24/2015 2:34 PM, deadalnix wrote:
>>> Maybe we want to fix the GC, exceptions and delegates or disable them in @safe
>>> code because they all cause implicit sharing.
>>
>> Andrei already filed a bug report on the GC issue. If there aren't bug reports
>> on the other two, file them.
>
> Well I filled a bug on the delegate one ~2 years ago, and the 2 others are
> features, not bugs, as far as I know.

Without examples and bug reports, I don't really know what you're talking about. At least with a bug report, you have something easy to link to instead of trying to explain it over and over again.

On Wednesday, 25 February 2015 at 00:20:25 UTC, Walter Bright wrote:
> On 2/24/2015 2:27 PM, deadalnix wrote:
>> I have to admit, that is pretty cool. But it is only gonna work with value types.
>
> I don't see that limitation at all.

Just try to do the same with opSlice() and you will see what he means.

On Tuesday, February 24, 2015 01:44:07 Walter Bright via Digitalmars-d wrote:
> On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
> > The issue is that delete is considered @safe by the compiler,
>
> I thought more people would be interested in how to do a memory safe reference counted container.

Oh, I think that that there's definitely something there and that we should be interested. I don't think that either Andrei or I were trying to take away from that. It's just that code showed a problem in that delete was considered @safe when it should be @system, so Andrei pointed that out, and then I agreed with him and pointed out that delete was really supposed to have been deprecated by now anyway. But the concept is perfectly valid, and delete can be replaced with destroy and core.memory.GC.free for the same effect without actually needing delete, so it'll still work even if delete is finally deprecated - though honestly, I would think that if you're going to be doing manual memory management, it would just be better to use malloc and free and avoid the GC altogether (though if the element type contains any references or pointers, you probably need to tell the GC about the memory so that it can scan it).

- Jonathan M Davis

On 2/24/15 3:34 PM, Walter Bright wrote:
> On 2/24/2015 6:56 AM, Steven Schveighoffer wrote:
>> Actually, RCArray can never be allocated on GC, or you may corrupt
>> memory. count
>> may be non-null, and point at invalid memory when the dtor is called.
>
> Just set count to null after the delete.

No, the GC may have already deallocated the memory count points at, and count is still non-null.

This is why you can never refer to GC-allocated memory in dtors, if they can be called from the GC.

>> Only safe way to do this is to C malloc/free the count. And yes, at
>> that point,
>> you need atomics.
>
> No, RCArray is not intended for shared access between threads.

GC is what shares the access. For instance, if you have an RCArray in one object that is being collected, it will attempt to decrement count. However, that doesn't mean that another RCArray reference in the originating thread won't also be trying to adjust count. In reality, it's only shared between the GC-collection running thread and the originating thread. I was not talking at all about making RCArray shared-usable.

As talked about before, running dtors in the originating thread can solve this problem.

-Steve

On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
> As talked about before, running dtors in the originating thread can
> solve this problem.

Yah, that will solve the nonatomic reference counting. What do you think about http://forum.dlang.org/thread/mcllre$1abs$1@digitalmars.com?

Andrei

On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote:
> As talked about before, running dtors in the originating thread can solve this problem.

This probably implies forcibly destroying objects whose creating thread terminated.