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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to