tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <>
Subject Re: Problem with (1.2.37) on iPlanet 7.0.15 and Solaris 11
Date Fri, 03 May 2013 15:01:46 GMT
On 05/02/2013 01:30 PM, Rainer Jung wrote:
> Especially since the nsapi docs for systhread_start only tell us that 
> the prio is an int depending on the platform and the only other source 
> of information, nsapi.h only contains a single defined prio, which is 
> SYSTHREAD_DEFAULT_PRIORITY. The other constants PR_PRIORITY_... are 
> defined in nspr/prthread.h and are enum elements of type 
> PRThreadPriority which formally don't qualify as arguments to 
> systhread_start(int prio, int stksz, void (*fn)(void *), void *arg) 
> which needs an int. 

Yeah, I didn't go as far as dealing with the type differences when 
complaining to them but I'll make that point as well when I update the 
call later today.
> I'm still not fully convinced, that PR_PRIORITY_* is correct and isn't 
> just working because PR_PRIORITY_NORMAL=1 is such a low number. When 
> you use PR_PRIORITY_NORMAL, can you see which priority the created 
> thread actually has? Probably using truss, since I think the thread 
> doesn't live long enough to be observable using "ps" with the "-L" 
> flag for threads and adding "pri" to the output format. Nevertheless 
> opening a bugzilla seems to be OK for tracking our progress on this 
> and making the problem publicly available. We might later decide on 
> resolving it as invalid though ;) 
Oh absolutely.  I actually looked at the NSPR code and found the chunk 
that does the conversion and at initial glance it's basically the math 
used allows PR_PRIORITY_NORMAL and LOW to work.

I went ahead and filed this in bugzilla:

I'll push this with Oracle, but if they refuse to budge, does it seem 
like there'd be no choice but to include an ugly hack to use 
PR_PRIORITY_NORMAL or something else?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message