digitalmars.D - COM server and GC
- xjc (7/7) Nov 07 2004 In the COM server sample, CHello object is allocated and managed by gc, ...
- xjc (5/12) Nov 09 2004 Please, would someone help me out? Nobody in this forum is interested in...
- Ilya Minkov (36/49) Nov 10 2004 Hm... Well, not really. I guess there are not too many people which are=...
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
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
xjc schrieb:Please, would someone help me out? Nobody in this forum is interested i=n writingMS 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 =not theobject 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... =20and theIn the COM server sample, CHello object is allocated and managed by gc,=theinterface pointer is returned to outer clients. How can the gc know if =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.object is referenced outside?cated byIt is specified that some solutions need to be present when memory allo=on??tgc is exposed to outer clients, such as adding a root to the gc so gc w=not findfree the memory. However I read through all the source files and could=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. -eyeany code that tells the gc not to free the CHello COM object.
Nov 10 2004