Closed luxapana closed 6 months ago
I assume you used OpenSSL with an older release https://www.openssl.org/blog/blog/2017/02/21/threads/index.html but this sounds about right.
You should verify with the crypto implementation you are using.
As Chris already hinted at that is part of openssl.
Jwt-cpp does not do any locking anywhere. It is the responsibility of the user to ensure threadsafety, however jwt-cpp also doesn't share anything outside respective object, so as long as you don't modify builder/verifier instances across multiple threads you are generally fine.
I can't comment on whether the locking/issue vtune found inside openssl is correct, but given the maturity and wide usage of openssl my guess would be yes.
Our app is working fine functionally as all threading issues being taken care of. This locking however is affecting the performance of the app where we have designed the app to have single threaded parts for optimum latency. Each of these single threaded execution units call jwt::decode which in turn locks a mutex in the call chain which affect the performance due to contention. We will dig deeper in to this and see what can be done. However I am not entirely sure why oppnssl need to acquire a lock in order to do a decryption.
However I am not entirely sure why oppnssl need to acquire a lock in order to do a decryption.
This is just a guess, but openssl supports hardware acceleration, which is not always multithreaded.
The only solution I could propose form our side is using another ssl library or reimplementing the crypto for the algorithm you need in your own code.
If your app is truly single threaded and does not use openssl from a different thread (or you make sure those calls don't happen concurrently) you can disable locking in openssl entirely by providing no-threads
to configure.
You might also want to look into using different versions of OpenSSL. In 3.0 they added a newer "default context" which is specially tied to the multithreading support https://www.openssl.org/docs/man3.0/man3/OSSL_LIB_CTX.html https://github.com/openssl/openssl/issues/17116
Going to mark this as closed since it's outside the scope of this library.
Feel free to open a new issue with your questions
What's your question?
I am using this library in a multi threaded app. Jwt::decode is called from multiple threads. Intel vtune thread profiler shows that inside libcrypto libary there is a read/write lock which is being locked within decode call chain. Just wanted to see if this is correct or not.
Additional Context
Tested in fedora 39,.