tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Bug that spans tomcat and tomcat-native
Date Tue, 28 Jun 2016 11:28:47 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message