In the COM server sample, CHello object is allocated and managed by gc, and the interface pointer is returned to outer clients. How can the gc know if the object is referenced outside?

It is specified that some solutions need to be present when memory allocated by gc is exposed to outer clients, such as adding a root to the gc so gc won¡¯t free the memory.  However I read through all the source files and could not find any code that tells the gc not to free the CHello COM object.

Please, would someone help me out? Nobody in this forum is interested in writing MS stuff using D?

Where in the sample is a reference to the created COM object saved? If not the object may be claimed by gc anytime...

In article <cmmci2$rtt$1@digitaldaemon.com>, xjc says...
>
>In the COM server sample, CHello object is allocated and managed by gc, and the interface pointer is returned to outer clients. How can the gc know if the object is referenced outside?
>
>It is specified that some solutions need to be present when memory allocated by gc is exposed to outer clients, such as adding a root to the gc so gc won¡¯t free the memory.  However I read through all the source files and could not find any code that tells the gc not to free the CHello COM object.
>
>

xjc schrieb:

> Please, would someone help me out? Nobody in this forum is interested in writing
> MS stuff using D?

Hm... Well, not really. I guess there are not too many people which are very fond of writing COM in D.

> Where in the sample is a reference to the created COM object saved? If not the
> object may be claimed by gc anytime...

GC doesn't collect stuff anytime, it only does so at allocation (thus allowing some guarantees for semi-realtime code), specifically when system is about to run out of RAM. From the first look i have, apparently "new" operator isn't called again after allocating the object

Note though that there are libraries - for example GUI tolkits - which may assume that you don't want to do any realtime work with them or try to figure that out by memory consumption and CPU usage, and thus could decide to actually call GC collection cycles suddenly.

> In article <cmmci2$rtt$1@digitaldaemon.com>, xjc says...
> 
>>In the COM server sample, CHello object is allocated and managed by gc, and the
>>interface pointer is returned to outer clients. How can the gc know if the
>>object is referenced outside?

I should take a look at the GC code - i think that though we are dealing with 2 GC code instances, both of them run in the same adress space and thus could (and should!) co-operate.

However this would be wrong in actual COM code, because, according to rumors (i have never dealt with COM myself), the liveness of an object is maintained through a manually kept index count.

>>It is specified that some solutions need to be present when memory allocated by
>>gc is exposed to outer clients, such as adding a root to the gc so gc won??t
>>free the memory.  However I read through all the source files and could not find
>>any code that tells the gc not to free the CHello COM object.

I believe it depends what sort of data your COM object stores... For instance, you as a user may pass it some data, and keep no copy to yourself, then it could explode someday if you don't make it a GC root. As to CHello itself, it probably shouldn't be allocated from the GC heap... But i don't know what is right or wrong. You can try to do some experiments on what strategy crashes the proram and what not - but you should initiate the garbage collection cycles explicitly.

One shot at finding more complex and correct COM examples would be the DirectX examples... I recall googling up some things or finding some on the Wiki4D, but it's a bit too late for today. Or perhaps too early, depending on the point of view.

-eye