www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - COM server and GC

reply xjc <xjc_member pathlink.com> writes:
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.
Nov 07 2004
parent reply xjc <xjc_member pathlink.com> writes:
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.

Nov 09 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
xjc schrieb:

 Please, would someone help me out? Nobody in this forum is interested i=

 MS stuff using D?

Hm... Well, not really. I guess there are not too many people which are=20 very fond of writing COM in D.
 Where in the sample is a reference to the created COM object saved? If =

 object may be claimed by gc anytime...

GC doesn't collect stuff anytime, it only does so at allocation (thus=20 allowing some guarantees for semi-realtime code), specifically when=20 system is about to run out of RAM. From the first look i have,=20 apparently "new" operator isn't called again after allocating the object Note though that there are libraries - for example GUI tolkits - which=20 may assume that you don't want to do any realtime work with them or try=20 to figure that out by memory consumption and CPU usage, and thus could=20 decide to actually call GC collection cycles suddenly.
 In article <cmmci2$rtt$1 digitaldaemon.com>, xjc says...
=20
In the COM server sample, CHello object is allocated and managed by gc,=


interface pointer is returned to outer clients. How can the gc know if =


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=20 thus could (and should!) co-operate. However this would be wrong in actual COM code, because, according to=20 rumors (i have never dealt with COM myself), the liveness of an object=20 is maintained through a manually kept index count.
It is specified that some solutions need to be present when memory allo=


gc is exposed to outer clients, such as adding a root to the gc so gc w=


free the memory.  However I read through all the source files and could=


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=20 instance, you as a user may pass it some data, and keep no copy to=20 yourself, then it could explode someday if you don't make it a GC root.=20 As to CHello itself, it probably shouldn't be allocated from the GC=20 heap... But i don't know what is right or wrong. You can try to do some=20 experiments on what strategy crashes the proram and what not - but you=20 should initiate the garbage collection cycles explicitly. One shot at finding more complex and correct COM examples would be the=20 DirectX examples... I recall googling up some things or finding some on=20 the Wiki4D, but it's a bit too late for today. Or perhaps too early,=20 depending on the point of view. -eye
Nov 10 2004