On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
> But in this case it is static, so why does it matter? Do you have any ideas how to wrap it or fix this?

It matters exactly because it is static. A code written for single-threaded environment may not work correctly in shared context. It simply wasn't written for it. The way to fix it is to write code for shared context.

On Friday, 11 September 2015 at 16:04:22 UTC, Kagamin wrote:
> On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
>> But in this case it is static, so why does it matter? Do you have any ideas how to wrap it or fix this?
>
> It matters exactly because it is static. A code written for single-threaded environment may not work correctly in shared context. It simply wasn't written for it. The way to fix it is to write code for shared context.

I don't care about "maybe" working. Since the array is hidden inside a class I can control who and how it is used and deal with the race conditions.

What I want is to be able to use Array so I don't have to rely on the GC. but since it complains about the ~this destruction, how can I fix that? If I wrap Array, and use a non-shared array inside it, I'll  still have the same problem because it will be thread local to the object? or is shared applied to all sub types of a class?

e.g.,

class MySharedArrayWrapper
{
    static Array!(int) a;

}

and instead I use

static shared MySharedArrayWrapper;

But a isn't marked shared, so will it be TLS, which put's me back at square one. Or it it marked shared, which then still complains?

Again, I'm asking how, not why.

On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
> I don't care about "maybe" working. Since the array is hidden inside a class I can control who and how it is used and deal with the race conditions.

You could use __gshared instead of shared. It means put it in non-tls storage, just like shared, but the compiler will not attempt to help you use it correctly; you're on your own for synchronization, etc.

> What I want is to be able to use Array so I don't have to rely on the GC.

But, again, built-in slices do NOT rely on the GC. Only specific methods on them do and you can use your own implementation for them.

On Friday, 11 September 2015 at 19:27:49 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
>> I don't care about "maybe" working. Since the array is hidden inside a class I can control who and how it is used and deal with the race conditions.
>
> You could use __gshared instead of shared. It means put it in non-tls storage, just like shared, but the compiler will not attempt to help you use it correctly; you're on your own for synchronization, etc.
>
>> What I want is to be able to use Array so I don't have to rely on the GC.
>
> But, again, built-in slices do NOT rely on the GC. Only specific methods on them do and you can use your own implementation for them.

Really?

Can you back up this claim? Not saying your lying, I'd just like to know it's true for a fact?

Ho wan you use "specific methods"? Do you mean I do not use new to allocate and use malloc(more or less)?

In that case, am I not essentially just re-creating Array? Obviously I can write my own array type and I can even write my own compiler, but that's no that the point, is it?

On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
> Can you back up this claim? Not saying your lying, I'd just like to know it's true for a fact?

The list of things that trigger the GC is pretty short. See the bottom of this page:

http://dlang.org/garbage.html

Basically, the three things that can do a gc allocation in a built in array are: increasing the length, the ~= and ~ operators, and the [a,b,c] literal syntax.

Slicing, indexing, etc, the other basic operations do not.

If you do: ubyte[] a = (cast(ubyte*) malloc(4)[0..4];, it will compile... and create a slice from the malloced memory. That's one way to create an array without GCing it.

> In that case, am I not essentially just re-creating Array?

Array does a lot of other stuff too... you only really need append and maybe shrink for a static variable, since tracking ownership doesn't matter (it is never disappearing since it is global)

On Friday, 11 September 2015 at 20:30:37 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
>> Can you back up this claim? Not saying your lying, I'd just like to know it's true for a fact?
>
> The list of things that trigger the GC is pretty short. See the bottom of this page:
>
> http://dlang.org/garbage.html
>
> Basically, the three things that can do a gc allocation in a built in array are: increasing the length, the ~= and ~ operators, and the [a,b,c] literal syntax.
>
> Slicing, indexing, etc, the other basic operations do not.
>
> If you do: ubyte[] a = (cast(ubyte*) malloc(4)[0..4];, it will compile... and create a slice from the malloced memory. That's one way to create an array without GCing it.
>
>> In that case, am I not essentially just re-creating Array?
>
> Array does a lot of other stuff too... you only really need append and maybe shrink for a static variable, since tracking ownership doesn't matter (it is never disappearing since it is global)

Oh really?!?! I thought slicing used the GC? Is this a recent development or always been that way?

ok, so if I just use a shared [], and create it using malloc(as you've done above) then release and remalloc when I need to append(not efficient but ok in my senario), then it won't use the GC?

If so, then I can handle that! I guess [] doesn't have a capacity field so I'll have to keep track of that. Other wise, it should be pretty simple.

Of course, I still feel like I'm trying to implement array because everything turns in to "lots of stuff" at some point ;/

On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
> Oh really?!?! I thought slicing used the GC? Is this a recent development or always been that way?

Always been that way. A D slice is just a C pointer + length packed together. A slice simply increments the pointer and/or decrements the length - no allocation needed.

GC can make slices more convenient, since you don't need to think about who owns that memory you're slicing to free it, but that's true of pointers and references and everything too.

> you've done above) then release and remalloc when I need to append(not efficient but ok in my senario), then it won't use the GC?

yeah.

you might want to GC.addRange it though so the contents are scanned anyway...

(btw the garbage collector is actually pretty nice, why are you avoiding it anyway?)

> I guess [] doesn't have a capacity field so I'll have to keep track of that. Other wise, it should be pretty simple.

Nope but you can just use realloc which does track some capacity for you. (Actually, the built-in ~= operator does that too, just with the GC instead of the C function. It sometimes won't reallocate because it knows it already has enough capacity. Read more here: http://dlang.org/d-array-article.html )

On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
>> Oh really?!?! I thought slicing used the GC? Is this a recent development or always been that way?
>
> Always been that way. A D slice is just a C pointer + length packed together. A slice simply increments the pointer and/or decrements the length - no allocation needed.
> (btw the garbage collector is actually pretty nice, why are you avoiding it anyway?)

Seems to be quite a lot of FUD wrt use of standard library and GC, which means also perhaps we don't communicate this point very well as a community.  Making Phobos GC-optional perhaps is an ultimate answer.  But people seem to think that you're back to C without the GC.

On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn wrote:
> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> > On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
> >> Oh really?!?! I thought slicing used the GC? Is this a recent development or always been that way?
> >
> > Always been that way. A D slice is just a C pointer + length
> > packed together. A slice simply increments the pointer and/or
> > decrements the length - no allocation needed.
> > (btw the garbage collector is actually pretty nice, why are you
> > avoiding it anyway?)
>
> Seems to be quite a lot of FUD wrt use of standard library and GC, which means also perhaps we don't communicate this point very well as a community.  Making Phobos GC-optional perhaps is an ultimate answer.  But people seem to think that you're back to C without the GC.

Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them.

Probably the may issue that actually requires a language change is that exceptions currently pretty much have to be GC-allocated whereas they really should be reference-counted (though possibly still GC-allocated, just not left for a garbage collection cycle), but exceptions are thrown rarely, meaning that the fact that they're GC allocated is really only a problem if you're trying to avoid the GC completely rather than just minimize its use, so it's rarely a problem. And there are plans to support reference-counted types in the language, in which case, the exception types would be change to use that Object hierarchy rather than the normal one.

So, we have improvements to make, but for the most part, I think that the idea that Phobos requires a GC is FUD. It's not completely false, but folks seem to think using Phobos means heavy GC usage, and for the most part, that's not true at all.

- Jonathan M Davis

On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis wrote:
> On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn wrote:
>> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
>> > [...]
>>
>> Seems to be quite a lot of FUD wrt use of standard library and GC, which means also perhaps we don't communicate this point very well as a community.  Making Phobos GC-optional perhaps is an ultimate answer.  But people seem to think that you're back to C without the GC.
>
> Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them.
>

I don't think it's that simple.

Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day.

It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6.