shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, September 14, 2015 14:19:30 Ola Fosheim Grøstad via Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
> The claim is correct: you need to follow every pointer that
> through some indirection may lead to a pointer that may point
> into the GC heap. Not doing so will lead to unverified memory
> unsafety.
>
> > Given one was written by one (very smart) student for his PhD
> > thesis, and that as I understand it that formed the basis of
> > Sociomantic's concurrent garbage collector (correct me if I am
> > wrong), and that this is being ported to D2, and whether or not
> > it is released, success will spur others to follow - it strikes
>
> As it has been described, it is fork() based and unsuitable for
> the typical use case.

I'm not sure why it wouldn't be suitable for the typical use case. It's
quite performant. It would still not be suitable for many games and
environments that can't afford to stop the world for more than a few
milliseconds, but it brings the stop the world time down considerably,
making the GC more suitable for more environments than it would be now, and
I'm not aware of any serious downsides to it on a *nix system.

Its achilles heel is Windows. On *nix, forking is cheap, but on Windows, it
definitely isn't. So, a different mechanism would be needed to make the
concurrent GC work on Windows, and I don't know if Windows really provides
the necessarily tools to do that, though I know that some folks were looking
into it at least at the time of Leandro's talk. So, we're either going to
need to figure out how to get the concurrent GC working on Windows via some
mechanism other than fork, or Windows is going to need a different solution
to get that kind of improvement out of the GC.

- Jonathan M Davis