Skip to content
Snippets Groups Projects
Commit 6800e3d4 authored by Jan Tattermusch's avatar Jan Tattermusch
Browse files

update the comment to reflect current state

parent 4d2df96f
No related branches found
No related tags found
No related merge requests found
...@@ -44,10 +44,9 @@ namespace Grpc.Core.Internal ...@@ -44,10 +44,9 @@ namespace Grpc.Core.Internal
{ {
/// <summary> /// <summary>
/// Represents a dynamically loaded unmanaged library in a (partially) platform independent manner. /// Represents a dynamically loaded unmanaged library in a (partially) platform independent manner.
/// An important difference in library loading semantics is that on Windows, once we load a dynamic library using LoadLibrary, /// First, the native library is loaded using dlopen (on Unix systems) or using LoadLibrary (on Windows).
/// that library becomes instantly available for <c>DllImport</c> P/Invoke calls referring to the same library name. /// dlsym or GetProcAddress are then used to obtain symbol addresses. <c>Marshal.GetDelegateForFunctionPointer</c>
/// On Unix systems, dlopen has somewhat different semantics, so we need to use dlsym and <c>Marshal.GetDelegateForFunctionPointer</c> /// transforms the addresses into delegates to native methods.
/// to obtain delegates to native methods.
/// See http://stackoverflow.com/questions/13461989/p-invoke-to-dynamically-loaded-library-on-mono. /// See http://stackoverflow.com/questions/13461989/p-invoke-to-dynamically-loaded-library-on-mono.
/// </summary> /// </summary>
internal class UnmanagedLibrary internal class UnmanagedLibrary
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment