On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
On Sunday, October 04, 2015 14:42:48 bitwise via
Digitalmars-d-learn wrote:
Since D is moving towards a phobos with no GC, what will
happen to things that are classes like Condition and Mutex?
Phobos and druntime will always use the GC for some things, and
some things just plain need classes. Rather, we're trying to
make it so that Phobos does not use the GC when it doesn't need
to use the GC as well reduce how much the GC is required for
stuff like string processing where lazy ranges can be used
instead in many cases.
I was under the impression that the idea was to _completely_
eliminate the GC. It says in Andre's 2015H1 vision statement:
"We aim to make the standard library usable in its entirety
without a garbage collector."
I understand the allocation/freeing of memory is expensive, but I
thought the actual sweep of the GC was a problem too, and that
disabling the GC to avoid the sweep was the plan for some people.
I don't know how long D's GC takes to sweep, but even a 5ms pause
would be unacceptable for a performance intensive game.
I guess if you use @nogc properly though, you could still safely
turn off the GC, right?
As for Condition and Mutex specifically, I don't know whey they
were ever classes except perhaps to take advantage of the
monitor in Object. Maybe they'll get changed to structs, maybe
they won't, but most D code is thread-local, and most of the
code that isn't is going to use message passing, which means
that explicit mutexes and conditions are unnecessary. So, most
code won't be impacted regardless of what we do with Condition
and Mutex.
You may be right. I wrote a simple download manager in D using
message passing. It was a little awkward at first, but in
general, the spawn/send/receive API seems very intuitive. It
feels awkward because the data you're working with is out of
reach, but I guess it's safer that way.
Regardless, I doubt that anything will be done with Condition
or Mutex until shared is revisted, which is supposed to happen
sometime soon but hasn't happened yet. What happens with shared
could completely change how Condition and Mutex are handled
(e.g. they don't support shared directly even though they
should probably have most of their members marked with shared,
because Sean Kelly didn't want to be doing anything with shared
that he'd have to change later).
- Jonathan M Davis
I'm not sure what's going to be done with shared, but I do think
it's annoying that you can't do this:
shared Array!int numbers;
someThread... {
numbers.clear(); // 'clear' is not shared
}
So this means that on top of the already ridiculous number of
attributes D has, now you have to mark everything as shared too =/
Bit
