during some issue investigating, I found binding erlang nif resource to Msquic 'objects' sometimes confused the user about the memory usage as some memory (big trunk buffer in msquic) will be freed only after the resource get deallocated by the VM after GC (resource dtor).
I think we should allow real 'close' API (which current map to shutdown) that close the handle and free the resource in msquic saftly while still keeping the VM resource callable but 'closed.' that is after the close, but before the GC, the resource could still stay with minimal mem usage while calling it will return {error, closed}.
during some issue investigating, I found binding erlang nif resource to Msquic 'objects' sometimes confused the user about the memory usage as some memory (big trunk buffer in msquic) will be freed only after the resource get deallocated by the VM after GC (resource dtor).
I think we should allow real 'close' API (which current map to shutdown) that close the handle and free the resource in msquic saftly while still keeping the VM resource callable but 'closed.' that is after the close, but before the GC, the resource could still stay with minimal mem usage while calling it will return
{error, closed}.