Garbage collection på COM-objekt?

Nu kan jag inte svara ja eller nej på din fråga, men kan däremot ge ett tips på att ändå frigöra minne innan GC'n kommer igång. Den vet man ju aldrig när den kör, så att fria minnet är ändå en bra grej att göra manuellt. :)

Jag tycker att .NET brukar ha svårt att släppa resurserna automatiskt (till com-objekt).
Använder mig alltid av:

System.Runtime.InteropServices.Marshal.ReleaseComObject(myObject);

När jag är färdig :)

Nu kan jag inte svara ja eller nej på din fråga, men kan däremot ge ett tips på att ändå frigöra minne innan GC'n kommer igång. Den vet man ju aldrig när den kör, så att fria minnet är ändå en bra grej att göra manuellt.

Du kan inte manuellt frigöra minnet i .NET (om du inte tvingar GC att köra). Om du sätter ett objekt till NULL/Nothing så betyder inte det att minnet är frigivet. Det betyder endast att du berättar för GC att dun inte vill använda objektet mer, och GC kan ta bort den när den körs. Sedan är det så att Kompilatorn är så smart att den fatta när du inte vill använda ditt objekt mer, så i många fall är det helt menningslöst att sätta ett objekt till NULL/Nothing eftersom kompilatorn ändå gör det till dig.

Så fort du dock börjar använd dig av objekt utanför .NET så blir kravet på dig större att städa upp efter dig, eftersom GC inte är så bra på detta. Generellt kan man säga om ett objekt har en Dispose/Close method så skall den alltid kallas när man är färdig med objektet. Sedan är det den metodens uppgift att städa upp efter sitt objekt.

- Magnus

Gladh skrev:

Sedan är det så att Kompilatorn är så smart att den fatta när du inte vill använda ditt objekt mer, så i många fall är det helt menningslöst att sätta ett objekt till NULL/Nothing eftersom kompilatorn ändå gör det till dig.

Egentligen är det inte kompilatorn utan runtimen som listar ut när objekt ligger och dinglar fritt :)

Gladh skrev:

Så fort du dock börjar använd dig av objekt utanför .NET så blir kravet på dig större att städa upp efter dig, eftersom GC inte är så bra på detta. Generellt kan man säga om ett objekt har en Dispose/Close method så skall den alltid kallas när man är färdig med objektet. Sedan är det den metodens uppgift att städa upp efter sitt objekt.

Ett hett tips är finalization. I "finaliseraren" anropar man sånt som behövs för att stänga objekt som inte nödvändigtvis stängs av GC:n (används främst i klasser som interagerar direkt med operativsystemet, typ fil- och nätverkshantering m.m.), så du borde kunna göra ett wrapperobjekt till COM-objektet, som anropar ReleaseComObject i sin finaliserare. Se bara till att inte ha några referenser direkt till COM-objektet som kan leva kvar efter att wrapperklassen samlats upp av GC:n!

Är inte finalization en motsvarighet på destructorn?

Om det är det så är det ju inget bra ställe att lägga funktioner för frigivning eftersom objekt så fall kommer att hålla resourser onödigt länge...

Vad man istället bör göra är att anropa Dispose methoden i finalization och ifall ingen har anropa Dispose så körs den methoden när runtimen kallar på finalization. De förutsätter dock att finalization och destructorn är "samma sak", vilket jag har fått för mig.

- M

Gladh skrev:

Är inte finalization en motsvarighet på destructorn?

Jo, det är det. I C# är destruktorn en del av finaliseringen.

Gladh skrev:

Om det är det så är det ju inget bra ställe att lägga funktioner för frigivning eftersom objekt så fall kommer att hålla resourser onödigt länge...

Självklart är bättre att fimpa resurser när de inte längre behövs, men det är aldrig fel med en extra liten safeguard som ser till att man inte får minnesläckor. Bl.a. filhantering och liknande är implementerat på det här sättet, d.v.s. att de stängs under finaliseringen om de inte redan stängts.

Gladh skrev:

Vad man istället bör göra är att anropa Dispose methoden i finalization och ifall ingen har anropa Dispose så körs den methoden när runtimen kallar på finalization. De förutsätter dock att finalization och destructorn är "samma sak", vilket jag har fått för mig.

Japp, det låter som en bra lösning. Det var ungefär det jag var ute efter, fast jag är inte så haj på dotnet och COM :)

Bra då är vi överrens.

- M