On Mon, Jun 27, 2016 at 12:17 PM, <therealnewo...@gmail.com> wrote: > On Mon, Jun 27, 2016 at 12:04 PM, <therealnewo...@gmail.com> wrote: >> On Mon, Jun 27, 2016 at 11:54 AM, Rainer Jung <rainer.j...@kippdata.de> >> wrote: >>> Great analysis. I was really wondering, what could make the hash map so huge >>> and hadn't thought about the hash function as the problem. >>> >>> Before OpenSSL 1.1.0 there's a callback for applications to provide their >>> own thread IDs: >>> >>> https://www.openssl.org/docs/man1.0.2/crypto/CRYPTO_THREADID_set_callback.html >>> >>> So we could probably work around the problem of the poor hashing function by >>> passing in IDs that work for hashing (pre-hashed ID?). Of course then we >>> loose the direct association of the OpenSSL thread ID with the real platform >>> thread id. >>> >>> Currently our callback in tcnative is ssl_set_thread_id() which refers to >>> ssl_thread_id(), which on Linux gets the ID from the APR function >>> apr_os_thread_current(). So we could add some hashing formula in >>> ssl_thread_id(). >> >> I think just using the real thread id would work, since now it isn't >> using the real thread id instead it is using the address location of >> errno. If this was the real thread id I think the hash algorithm and >> bucket selection they have now will work much better since the thread >> ids are basically numerically increasing and aren't aligned to powers >> of 2. > > Sorry, I need to read code a bit closer. I misread the > OPENSSL_VERSION_NUMBER < 0x10100000L as version < 1.0.1 and not 1.1.0. > > I would still expect real thread ids to provide enough of a > distribution in a map where the hash bucket ends up being is ((ID * > 13) & 0X7F).
OK, this now makes more sense apr_os_thread_current() calls pthread_self() which returns a pthred_t which is basically a handle for pthread's internal state and not an actual ID. It might be better to use gettid(), but that isn't as portable. -nate --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
