On 28/06/2016 11:34, Rainer Jung wrote: > Am 28.06.2016 um 11:15 schrieb Mark Thomas:
<snip /> >> Index: src/ssl.c >> =================================================================== >> --- src/ssl.c (revision 1750259) >> +++ src/ssl.c (working copy) >> @@ -420,6 +420,10 @@ >> return psaptr->PSATOLD; >> #elif defined(WIN32) >> return (unsigned long)GetCurrentThreadId(); >> +#elif defined(DARWIN) >> + uint64_t tid; >> + pthread_threadid_np(NULL, &tid); >> + return (unsigned long)tid; >> #else >> return (unsigned long)(apr_os_thread_current()); >> #endif >> >> >> I want to do some similar testing for Linux before adding what I suspect >> will be a very similar block using gettid(). > > We could either add something to configure.in. Untested: > > Index: native/configure.in > =================================================================== > --- native/configure.in (revision 1750462) > +++ native/configure.in (working copy) > @@ -218,6 +218,9 @@ > *-solaris2*) > APR_ADDTO(TCNATIVE_LIBS, -lkstat) > ;; > + *linux*) > + APR_ADDTO(CFLAGS, -DTCNATIVE_LINUX) > + ;; > *) > ;; > esac > > > and then use a > > #ifdef TCNATIVE_LINUX > > or we copy some other more direct linux check from e.g. APR: > > #ifdef __linux__ > > The latter looks simpler, but the version above is based on all the > logic put into config.guess. I'd go with the __linux__ option as that is consistent with what we already use in os/unix/system.c I'm not against the change to configure.in, I just think we should be consistent with how we do this throughout the code base. >> I do think OS specific code to get the real thread ID is the way to go >> here until we can switch to OpenSSL 1.1.0 at which point the problem >> should go away. > > Agreed, but cleaning up at the end of a thread would be good as well, > e.g. if the executor is configured to renew threads when a context is > reloaded we can accumulate lots of old hash entries. Agreed. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
