The ___release_rc_tls_context function is passed to ___NONNULLPOINTER_to_SCMOBJ to build the foreign obj (scm_ctx) that is returned to Scheme:
if ((scm_e =___NONNULLPOINTER_to_SCMOBJ (___PSTATE, ___CAST(void*,c), ___FAL, ___release_rc_tls_context, &scm_ctx, ___RETURN_POS)) != ___FIX(___NO_ERR)) { ___release_rc_tls_context (c); return scm_e; }
So the ___release_rc_tls_context function will be called when the foreign object is reclaimed by the GC.
Marc
On Mar 26, 2018, at 3:47 AM, Dimitris Vyzovitis vyzo@hackzen.org wrote:
Wrt question 2, experiments suggest that the tls context can be safely reused.
-- vyzo
On Mon, Mar 26, 2018 at 10:38 AM, Dimitris Vyzovitis vyzo@hackzen.org wrote: Marc,
Post refcount release bug, I've been looking more closely into the implementation of tls contexts, and I have a couple of questions
The tls context contains internally allocated data, that is released immediately with ___release_rc_tls_context in failure paths of ___os_make_tls_context. However, I am not convinced it gets cleaned up when the tls context is reclaimed by the gc. Is there a finalizer for tls contexts or do we leak that internal memory?
Is there a need to make a tls context per socket or can the tls context be reused and shared among many (concurrent) sockets? Currently I make a new context every time I make an https request, but it would be very nice if a single context could be reused.
-- vyzo