[
https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792727#comment-13792727
]
James Peach commented on TS-2271:
---------------------------------
The TSThreadInit() and TSThreadDestroy() APIs are provided for plugins to
integrate their own threads with the Traffic Server threading model. When the
plugin spawns a thread, the first thing that thread should do is call
TSThreadDestroy().
As for the OpenSSL callbacks, I think that you need to examine your linking
options to ensure that your plugin links it's own, independent copy of OpenSSL
(including static data). There's no guarantee that Traffic Server links to
OpenSSL and there's no guarantee that Traffic Server configures the OpenSSL
runtime in a way that works for your plugin. If there's no way to give the
plugin an independent copy, I'd be happy to discuss further, but that's my
initial reaction ;)
> Threaded plugin support with 3rd party libraries
> ------------------------------------------------
>
> Key: TS-2271
> URL: https://issues.apache.org/jira/browse/TS-2271
> Project: Traffic Server
> Issue Type: Wish
> Components: Plugins
> Reporter: Heikki Hannikainen
>
> We have created an ATS plugin which links to a library (an existing one which
> is widely deployed in our other products). That library *creates threads* and
> *links with openssl*. It's not an option at this point to rework that library
> to use ATS threading functions.
> The library will, in the end, call a callback function provided by our ATS
> plugin. That call happens from a thread created by the library (outside TS
> and plugin code). That callback function will then re-enable a transaction.
> There are two problems:
> # The library creates threads, and then calls openssl in those threads, and
> openssl in turn calls mutex/thread id functions provided by ATS
> (*SSL_pthreads_thread_id*, *SSL_locking_callback*). The functions provided by
> ATS bail out if they don't know about the threads of the 3rd-party library.
> # The callback function called by the library needs to re-enable a
> transaction. The *TSHttpTxnReenable* API function bails out if called from a
> thread created by the 3rd-party library.
> To work around the OpenSSL-in-threads issue I changed the callbacks to use
> regular pthread functions directly.
> [https://github.com/hessu/trafficserver/commit/34b8455518a3e8093d935412c03cfdd3cb5ea398]
> To re-enable transactions I made *TSHttpTxnReenableFromThread* which doesn't
> try to look up an EThread. That would fail and the server would quit.
> https://github.com/hessu/trafficserver/commit/0038e9ff1584513fdf8dc96bdd7b2fe12f046fe3
> How does the ATS project feel about this use case (plugin with library which
> uses threads)? Should ATS support it directly somehow?
> I understand that the requirement might be pretty rare, and that the patches
> are not something that should go in ATS as they are (especially the SSL
> threading callbacks, it's now a bunch of almost-duplicate code). I'm just
> publishing them to describe the workarounds and help discussion. We can live
> with a fork with 3 patches on top.
> I'd also be happy to hear about better workarounds.
> TSHttpTxnReenableFromThread appears to have a measurable latency (~10ms).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
