[
https://issues.apache.org/jira/browse/PROTON-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201864#comment-16201864
]
Alan Conway commented on PROTON-1620:
-------------------------------------
We might be able to solve this without locks - if pn_ssl_init() uses or copies
all the domain data it needs before it returns then there's no need to touch
its refcount. I don't know if that's the case now, but we could make it so.
Then we just have to document that pn_ssl_init is thread-unsafe like all the
other pn objects and its up to the user to ensure no concurrent changes to the
domain etc. The user only needs to ensure that the domain is valid and not
being modified concurrently at the time they call pn_ssl_init() - when that
returns we will have no more references to the domain.
> TLS / SSL thread safety with proactor
> -------------------------------------
>
> Key: PROTON-1620
> URL: https://issues.apache.org/jira/browse/PROTON-1620
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.18.0
> Reporter: Cliff Jansen
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own
> private pn_ssl_t objects may mess up the refcount of the shared
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its
> security context thingies. That may get automatically solved by the above,
> or may require a separate JIRA to track. The same may apply to openssl.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
