-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
investigate avoiding to copy binary data when marshaling byte[] to Buffer #34
Comments
This looks interesting: http://msdn.microsoft.com/en-us/magazine/cc163910.aspx#S2 Can the CLR buffer be pinned for the lifetime of the node.js Buffer instance created around it? That is, can the CLR buffer only be unpinned when the node.js Buffer is garbage collected? Does the JS Buffer assume it owns the memory? Can CLR byte[] be garbage collected while the underlying memory is pinned? To be or not to be? |
I'd look at it the other way around. Allocate a chunk of native memory and provide it to the CLR as the pointer to the managed byte array. You can then also share the same native memory with a nodeJs Buffer instance. Regarding GC and pinning, the entire idea behind pinning is that the GC no longer touches that memory. There is a design reason behind why the I would be looking at the internal code behind See |
A few more interesting things: #include <vcclr.h>
using namespace System;
using namespace System::Runtime::InteropServices;
void WriteStringManaged (const wchar_t* str)
{
Console::WriteLine (Marshal::PtrToStringUni ((IntPtr) (void*) str));
}
int main (array<System::String^> ^args)
{
Console::WriteLine (L"Pure MSVCRT console application");
pin_ptr<const wchar_t> str = PtrToStringChars (L"WriteStringManaged");
WriteStringManaged (str);
return 0;
} |
Is there any information on this? I'm having some memory leak issues due to byte[] being copied when passing it back. For now I'm directly calling the GC to cleanup but I was wondering if there's any good solution for this. |
See #4 (comment)
The text was updated successfully, but these errors were encountered: