From Chris Saari: The idle_thead acting as a queue scheduler for I/O blocked threads and having a low priority are inverse goals. When I/O completes, you want the thread blocked on the I/O to run as quickly as possible. In UNIX systems, this usually means having threads waiting on I/O have a high priority, usually kernel level, but not be runnable until the I/O completes. Just before the blocked thread runs again, the priority is set back to it's normal user level priority. How does this relate to NSPR threading on the Mac: I'd like to have the I/O completion routine AsyncIOCompletion bump up the idle_thread priority if it fails to schedule the blocked thread itself because of a lock on the queues. The idle_thread itself can reset it's priority back to normal when it is run. Thread priority is an issue that we may wish to address further. The current 5 level priority and round robin scheduling

Reassigned the bug to gordon.

Changed target milestone to M6.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Sounds like this should be a sched bug. need estimated remaining duration in status whiteboard field

per discussion with saari this work is well beyond the scope of what we can do in the PorkJet timeframe. We also need to look at Apple's MP API which is what they indicate is now the preferred thread API. There's also the potential availability of pthreads when running under Carbon on Mac OS X to be considered so it's conceivable the current NSPR Mac threading model could be replaced by 2 different implementations depending on the target OS.

phillip gone, removing him from qa contact, sorry for spam

For Mac OS X it would appear certain that we will use native pthreads. It is not clear that we will ever actually re-write our thread code for the current/older Mac OS. Punting to M17.

reassigning to saari. May not have time for this, so putting on helpwanted radar. Use of JAR files may lessen the need for this, so it is a candidate for latering. cc warren

After talking with sfraser, it looks like JARs will be the big win here. This change would have a similar effect, but with the advent of JARs, this change's impact on startup time would be reduced. Now, we need to know that JARs will be performant on MacOS...

Mass move of all M20 bugs to M30.

can't move past M20, so resolving as remind.

REMIND is deprecated per bug 35839. Futuring.

Is this bug still valid in the FizzillaMach era? It doesn't sound as though it is, per comment 7.

This bug is about the old CFM version of NSPR. Marked the bug WONTFIX.