-
Notifications
You must be signed in to change notification settings - Fork 51
AddRef Release Semantics
NOTE: This section applies only when consuming the Concord API from native code.
If you aren't familiar with COM, please read the intro documentation first.
The native Concord API adheres to standard COM conventions for AddRef/Release. If an object is returned as the return value, this is done without increasing the ref count on the object. If the object comes back as an out parameter, Release should be called. The Dispatcher will guarantee that any input object to a Concord interface method will stay valid until the implementer returns from the method. It will also guarantee that if an object provides an accessor method which returns another object, then this return value is immutable and doesn’t need to be AddRef’ed/Release’ed (though doing so will certainly not hurt anything). Examples to illustrate these rules:
{
DkmThread* pDkmThread = pDkmProcess->Thread();
pDkmThread->Release(); // BUG: pDkmThread should not be Released
}
{
DkmThread* pDkmThread;
pDkmProcess->FindSystemThread(12, &pDkmThread);
} // BUG: pDkmThread is leaked; pDkmThread->Release() must be called
{
// Correct, but the extra AddRef/Release that CComPtr will add isn't required
// as long as the code isn't somehow releasing its reference to DkmProcess
CComPtr<DkmThread> pDkmThread = pDkmProcess->Thread();
}
Concord Documentation:
- Overview
- Visual Studio 2022 support
- Concord Architecture
- Getting troubleshooting logs
- Tips for debugging extensions
- Component Discovery and Configuration
- Component Levels
- Navigating the Concord API
- Obtaining the Concord API headers, libraries, etc
- Concord Threading Model
- Data Container API
- Creating and Closing Objects
- Expression Evaluators (EEs)
- .NET language EEs
- Native language EEs
- Installing Extensions
- Cross Platform and VS Code scenarios:
- Implementing components in native code:
- Worker Process Remoting
Samples: