I can't create a shared array:

static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;

(prepending shared produce a ton of errors with the Array class)

I've tried making it a pointer and other things.


The array must be static and must be shared. Without shared everything works but I don't get, obviously, a useful array(it's empty because all the updating goes on in the main thread).

1. How do I create a shared array?
2. Why prepending shared produces any problems? I thought shared simply made a variable global to all threads?

On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
> static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;

Try just using a regular array instead of the library Array.


static bool delegate(int, WPARAM, LPARAM)[] callbacks;

my guess is the Array library thing isn't marked as shared internally.

On Friday, 11 September 2015 at 00:50:15 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
>> static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
>
> Try just using a regular array instead of the library Array.
>
>
> static bool delegate(int, WPARAM, LPARAM)[] callbacks;
>
> my guess is the Array library thing isn't marked as shared internally.

I thought about that but then I have to rely on the GC for some simple things. Doesn't seem like the right way to go.

I get only one error:
Error: non-shared method std.container.array.Array!(void delegate()).Array.~this is not callable using a shared object.

It will try to destruct the array on program termination, but it requires the destructor to be aware of the shared context.

You can try to write a wrapper for the array that it aware of concurrency.

On Friday, September 11, 2015 00:50:13 Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
> > static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
>
> Try just using a regular array instead of the library Array.
>
>
> static bool delegate(int, WPARAM, LPARAM)[] callbacks;
>
> my guess is the Array library thing isn't marked as shared internally.

Given how shared works, for a class or struct to work with shared, it pretty much has to be designed specifically to be used with shared. Depending on its members, it's possible to declare a variable of class or struct type as shared and then cast away shared to operate on it (after protecting access to it with a mutex of course), but actually using an object as shared is impossible unless the type was specifically designed to be used that way, and even marking one as shared with the idea that you'll cast away shared to operate on it (after protecting it with a mutex) probably won't work in many cases simply because the type's internals weren't designed to work with shared and could end up with compilation errors even if it was never actually going to be used without casting away shared.

In general, shared should only be used with built-in types or types which were specifically designed to be shared, and that means that types that you'd use in non-shared code aren't going to work in shared code. This can be annoying, but it really forces you to separate out your shared code from your normal code, which is arguably a good thing. Still, shared is one of those things that we need to re-examine and see how it should be changed to be more usable. It's a great idea, but the devil is in the details.

- Jonathan M Davis

On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
> I thought about that but then I have to rely on the GC for some simple things. Doesn't seem like the right way to go.

Since it is static, it will never be collected anyway, so you could just use it and it'll work for convenience and probably lose nothing, or very trivially write an append function that uses any scheme you want instead of doing ~= on it without even worrying about freeing it.

On Friday, 11 September 2015 at 13:12:14 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
>> I thought about that but then I have to rely on the GC for some simple things. Doesn't seem like the right way to go.
>
> Since it is static, it will never be collected anyway, so you could just use it and it'll work for convenience and probably lose nothing, or very trivially write an append function that uses any scheme you want instead of doing ~= on it without even worrying about freeing it.

And that makes it worse!! If it's never collected and the GC scans it every time, it means it adds a constant overhead to the GC for absolutely no reason, right? It also then makes every dependency on it GC dependent(@nogc can't be used)? It just seems like it's the wrong way to go about it.

On Friday, 11 September 2015 at 07:41:10 UTC, Kagamin wrote:
> I get only one error:
> Error: non-shared method std.container.array.Array!(void delegate()).Array.~this is not callable using a shared object.
>
> It will try to destruct the array on program termination, but it requires the destructor to be aware of the shared context.

But in this case it is static, so why does it matter? Do you have any ideas how to wrap it or fix this?

On Friday, 11 September 2015 at 14:47:15 UTC, Prudence wrote:
> If it's never collected and the GC scans it every time, it means it adds a constant overhead to the GC for absolutely no reason, right?

GC overhead isn't quite constant, it happens only when you call for a collection cycle.

But the array would still be scanned to clean up dead objects referred to by the delegates. The array itself is never collected (since it is always referenced by the global), but if you null out some entries, the objects they pointed to may be collected.

> It also then makes every dependency on it GC dependent(@nogc can't be used)? It just seems like it's the wrong way to go about it.

You can access an array without the GC. And if you manually allocate it, then there's no GCness to it at all.

Built in arrays and slices are not necessarily managed by the garbage collector. It depends on how you create and use them.