legacy dll callback and pinning pointer

  • Thread starter Thread starter Sai Kit Tong
  • Start date Start date
S

Sai Kit Tong

I have to interface managed application with my legacy dll. I have employed
the wrapper approach but I have to deal with the asynchronous callback from
the legacy dll, which likely goes through a thread other than the initial
calling thread. I got the idea from MSDN and other articles
on using the delegate. However, for garabage collection issue, I need to pin
the delegate. Since my callback is asynchronous, I have been thinking about
create that __pin pointer within my wrapper and route the callback
through the wrapper class member function. However, .NET doesn't allow a
__pin pointer data member. What should be the proper practice to prevent
that callback delegate from being moved by garbage collection? The callback
existance have to last for the lifetime of the application - HW events.

If the callback is created for an instance method, do we have to pin both
the delegate and the object itself?
 
Hi,

Thanks for your post. As I understand, you want to pass a managed delegate
out to an unmanaged DLL. Please correct me if there is any
misunderstanding. Now I'd like to share the following information with you:

1. Based on my experience, there is no need to __pin the managed delegate.
Per MSDN article below, delegates are of non-blittable type. That is, it
will be marshaled to an unmanaged function point. Subseque calls from
unmanaged code will return you to the AppDomain the delegate was marshaled
out of, and now you are executing a managed object on a managed instance.

Blittable and Non-Blittable Types
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconblittablenon-blittabletypes.asp

2. As you know, it's no supported to have a __pin pointer data member. You
can call GCHandle.Alloc(..., GCHandleType::Pinned) to have a referenced
object pinned. Please refer to the following documentations:

GCHandle Structure
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemRuntimeInteropServicesGCHandleClassTopic.asp

GCHandleType Enumeration
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemruntimeinteropservicesgchandletypeclasstopic.asp?frame=true

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Tian,

Thank you for the response. I went through both links as suggested. I also
went to the
page on "Default Marshaling for Delegates":
http://msdn.microsoft.com/library/d...e/html/cpcondefaultmarshalingfordelegates.asp

I would like to confirm on my understanding:

- Two managed objects are involved to set up asynchronous callback from the
unmanaged dll to the instance method of a managed object - the delegate
object and the managed object itself.
- We don't need to pin the delegate object as you mentioned - but I didn't
find your quote
the page:
Subseque calls from
unmanaged code will return you to the AppDomain the delegate was marshaled
out of, and now you are executing a managed object on a managed
Click to expand...
instance.
- We need to keep the managed object alive to prevent it garabage collected.

However, I am not sure whether the marshaling will also keep track of the
movement of the managed object - Garbage Collector can move any object in
the GC heap during its operation.
Hence, do we need to create a GCHandle for the managed object?
 
Hi,

The words " Subseque calls from unmanaged code will return you to the
AppDomain the delegate was marshaled out of, and now you are executing a
managed object on a managed instance." is not quoted from any document.

Interop marshaling governs how data is passed in method arguments and
return values between managed and unmanaged memory during calls. Interop
marshaling is a run-time activity performed by the common language
runtime's marshaling service. So that, we need not worry about the movement
of managed object moved by GC. That is, there is no need to use GCHandle to
__pin the object.

Default Marshaling for Delegates
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconblittablenon-blittabletypes.asp

Please feel free to let me know if you have any problems.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Thanks for the information. This really simplifies the entire issue and I
will just focus on pinning the managed object responsible for handling the
callback.
 
Back
Top