GC, the simple solution

[Sean Kelly]

Walter Bright wrote:
> Sean Kelly wrote:
>> Derek Parnell wrote:
>>> On Thu, 08 Jun 2006 22:18:24 -0700, Walter Bright wrote:
>>>
>>>
>>>> The approach most real time programmers use to deal with this is to 
>>>> preallocate all needed data before entering the real time section, 
>>>> and the real time section does no malloc's or free's.
>>>>
>>>> Also, you can use malloc and free in D, in exactly the same way you 
>>>> would in C.
>>>
>>> It seems obvious that if one doesn't want the Garbage Collector to 
>>> collect
>>> garbage, one doesn't create any garbage for it to collect. ;-)
>>
>> This gets sticky if one wants to use strings in D though, as there's 
>> no real way to make them work outside of the garbage collector mechanism.
>> Sure we could use C-style pointers, but it's not a terribly attractive 
>> option.
> 
> You can use D arrays. Just allocate them using malloc (or statically 
> allocate them). Don't concatenate them.

So then I'd just manually set the ptr and len members?  Sounds 
reasonable, provided everyone behaves and uses the copy on write idiom 
you suggest.

> Though I would ask why the real time code was allocating strings?

I was mostly thinking about this in the context of just how much 
allocation pretty much must be performed by the GC for applications with 
special memory requirements (gigabytes of data, for example).  It just 
seemed to have an overlap insofar as this sort of programming is concerned.

> C is very good for writing real time code, and you can write "C"-style 
> code in D, and it will behave exactly like the corresponding C code. You 
> can call printf, strcpy, malloc, etc., which will behave just like C's 
> printf, strcpy, and malloc because they *are* C's functions. It will not 
> do a gc collect unless the code allocates gc memory, and it will ONLY do 
> a gc collect during such an allocation.

At times I've considered extending thread support to allow for the 
creation of detached threads, but it simply seems to error-prone to be 
worthwhile.  I think you're right in that if someone is doing real-time 
programming then they shouldn't expect much hand-holding, because the 
assumptions involved offer too great a risk of unexpected behavior.

> Heck, my old Empire game was written in C. I renamed the files from .c 
> to .d, did a few minor syntactic edits, and voila! it was now in D. It 
> runs exactly the same.

Yup.  Though it's worth noting that D has been heavily influenced by 
your particular programming style.  Not at all a bad thing, but it does 
imply that you are less likely than anyone else to experience code 
translation problems :-)  On a related note, I sometimes wonder if Sid 
Meier credits you anywhere for effectively creating the genre that's 
made him so successful ;-)

> But the bottom line is that a real time thread should not be doing 
> storage allocation. It shouldn't be calling new, or malloc. It shouldn't 
> do storage allocation regardless of whether it is written in D, C, C++, 
> or assembler.

True enough.


Sean
Sean