On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
Walter Bright, el  7 de October a las 13:06 me escribiste:
On 10/6/2014 9:51 AM, Dicebot wrote:

Thank you. This is great progress!

I understand the caveats, but can this be put into a shape where it
can be pulled despite being a work in progress? I.e. have the code
be disabled by default? That will help encourage the community to
help out with the gaps.

Yes, I think that's the best approach too. Ideally this should be
configurable at runtime as Marting suggested, so ANYONE can try it with
their applications by just running it like this:
D_GC=concurrent=1 ./myapp

Then bugs can be filled more easily and people can work on fixing them
more easily too. At some point I'd like to see the current GC and the
concurrent GC merged, the concurrent GC already support disabling the
concurrency. Both GCs diverged with time and both have (different)
improvements over the common parent, and it will be a shame to lose any
of them.

That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently being left on, or off, or set for some unrelated purpose. It also would affect all D executables on the system, potentially making a big mess.

And there's always:

  user: "my program used to work, now it is too big / too slow / crashes"
  n.g.: "did you check that D_GC is not in your environment?"
  user: "yes I checked, it isn't set"
  n.g.: "check again"
  [lots of fruitless back and forth a few times]
  user: "oops, sorry!"

Sort of like:

  user: "need to fix this on the website"
  n.g.: "thanks! fixed now!"
  user: "no it isn't"
  n.g.: "looks good to me"
  [lots of fruitless back and forth]
  n.g.: "did you refresh your browser's cache?"
  user: "oops, sorry!"

Reply via email to