Marc,
Post refcount release bug, I've been looking more closely into the implementation of tls contexts, and I have a couple of questions
1. 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?
2. 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
Afficher les réponses par date
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
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
ok, thanks! I missed that nuance.
-- vyzo
On Mon, Mar 26, 2018 at 3:34 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
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 contextis reclaimed by the gc.
Is there a finalizer for tls contexts or do we leak that internalmemory?
- 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
-
Dimitris Vyzovitis -
Marc Feeley