You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by mt...@apache.org on 2009/12/15 11:14:28 UTC
svn commit: r890738 - /tomcat/jk/trunk/native/common/jk_util.c
Author: mturk
Date: Tue Dec 15 10:14:28 2009
New Revision: 890738
URL: http://svn.apache.org/viewvc?rev=890738&view=rev
Log:
Use better thread id logic. Use 4/8 byte alignment
Modified:
tomcat/jk/trunk/native/common/jk_util.c
Modified: tomcat/jk/trunk/native/common/jk_util.c
URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_util.c?rev=890738&r1=890737&r2=890738&view=diff
==============================================================================
--- tomcat/jk/trunk/native/common/jk_util.c (original)
+++ tomcat/jk/trunk/native/common/jk_util.c Tue Dec 15 10:14:28 2009
@@ -2125,13 +2125,16 @@
pthread_getunique_np(&(u.tid), &tid);
return ((jk_uint32_t)(tid.intId.lo & 0xFFFFFFFF));
#else
- switch(sizeof(pthread_t)) {
- case sizeof(jk_uint32_t):
- return *(jk_uint32_t *)&u.tid;
- case sizeof(jk_uint64_t):
- return (*(jk_uint64_t *)&u.tid) & 0xFFFFFFFF;
- default:
- return 0;
+ switch (sizeof(pthread_t)) {
+ case sizeof(jk_uint32_t):
+ return ((jk_uint32_t)u.tid >> 2);
+ break;
+ case sizeof(jk_uint64_t):
+ return (jk_uint32_t)((((jk_uint64_t)u.tid) >> 3) & 0xFFFFFFFF);
+ break;
+ default:
+ return 0;
+ break;
}
#endif /* AS400 */
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r890738 - /tomcat/jk/trunk/native/common/jk_util.c
Posted by Mladen Turk <mt...@apache.org>.
On 12/15/2009 02:12 PM, Rainer Jung wrote:
>
> Why is that better?
Uses significant bits out of pthread pointer.
> I'm concerned, that it breaks thread id's as logged
> by other components. For instance on Solaris I think the thread id
> logged by mod_jk is the same as by httpd when using %{tid}P in the
> access log
They are logged as 64 bit numbers on 64 bit builds, while our is
casted to the lower 32 bits.
>
> What does the above change result in w.r.t. aligning our thread id with
> the one in Apache?
>
The solution would be to use something like on httpd:
apr_psprintf(r->pool, "%pT", &tid)
which takes care if the pointer is 32/64 and prints it correctly.
Without that stripping upper 32 bits and logging that number makes no
sense whatsoever.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r890738 - /tomcat/jk/trunk/native/common/jk_util.c
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Mladen,
On 15.12.2009 11:14, mturk@apache.org wrote:
> Author: mturk
> Date: Tue Dec 15 10:14:28 2009
> New Revision: 890738
>
> URL: http://svn.apache.org/viewvc?rev=890738&view=rev
> Log:
> Use better thread id logic. Use 4/8 byte alignment
>
> Modified:
> tomcat/jk/trunk/native/common/jk_util.c
>
> Modified: tomcat/jk/trunk/native/common/jk_util.c
> URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_util.c?rev=890738&r1=890737&r2=890738&view=diff
> ==============================================================================
> --- tomcat/jk/trunk/native/common/jk_util.c (original)
> +++ tomcat/jk/trunk/native/common/jk_util.c Tue Dec 15 10:14:28 2009
> @@ -2125,13 +2125,16 @@
> pthread_getunique_np(&(u.tid),&tid);
> return ((jk_uint32_t)(tid.intId.lo& 0xFFFFFFFF));
> #else
> - switch(sizeof(pthread_t)) {
> - case sizeof(jk_uint32_t):
> - return *(jk_uint32_t *)&u.tid;
> - case sizeof(jk_uint64_t):
> - return (*(jk_uint64_t *)&u.tid)& 0xFFFFFFFF;
> - default:
> - return 0;
> + switch (sizeof(pthread_t)) {
> + case sizeof(jk_uint32_t):
> + return ((jk_uint32_t)u.tid>> 2);
> + break;
> + case sizeof(jk_uint64_t):
> + return (jk_uint32_t)((((jk_uint64_t)u.tid)>> 3)& 0xFFFFFFFF);
> + break;
> + default:
> + return 0;
> + break;
> }
> #endif /* AS400 */
> }
Why is that better? I'm concerned, that it breaks thread id's as logged
by other components. For instance on Solaris I think the thread id
logged by mod_jk is the same as by httpd when using %{tid}P in the
access log. On Linux there are two different thread ids, one in the type
of the pid, and another one which usually produces large numbers.
What does the above change result in w.r.t. aligning our thread id with
the one in Apache?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org