Oracle has agreed this is a bug. I've got a query into them to find out
what their ETA is.
Andy
On 05/03/2013 10:01 AM, Andy Wang wrote:
> 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:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54923
>
> 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?
>
> Thanks,
> Andy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
|