On Tuesday, 29 May 2018 at 21:06:52 UTC, Jonathan M Davis wrote:
On Wednesday, May 30, 2018 08:43:33 rikki cattermole via
Digitalmars-d wrote:
On 30/05/2018 8:37 AM, Tony wrote:
> On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote:
>> I don't think it's difficult to do that yourself. There's
>> no need to have a formal split. One example is that it's
>> really nice to have the GC available for part of the
>> program and avoid it for another part. @nogc gives you a
>> guarantee. Different variants of the language are a special
>> case of this that is equivalent to annotating the entire
>> program to restrict behavior. That's rarely desirable.
>
> What would be an example of a type of application (or maybe
> that should be "which type of domain" or "which type of
> developer") where you would want part of it to do garbage
> collection and the rest of it do not do garbage collection?
GUI's, audio systems, language tooling, games, I'm sure
somebody can come up with a much more longer list.
Basically, stuff that can't afford to have the GC pause the
program for more than a millisecond or two has to be careful
with the GC, but your average program is going to be perfectly
fine with it, and in many cases, it's just part of the program
that can't afford the pause - e.g. a thread for an audio or
video pipeline. The rest of the program can likely afford it
just fine, but that thread or group of threads has to be at
least close to realtime, so it can't use the GC.
You cant call any code that might take a lock if you're doing
real time audio, so that means no malloc/free either. That's
standard practice. You either allocate everything up front or you
do something like I do which is lock free queues ferrying things
to and from the audio thread as needed.
I mean the point is needing different memory management for
different parts of the program is already a thing with real time
audio, GC doesnt really change that.
