It would be beneficial if the I/O buffering mechanism controlled thread blocking within NSPR instead of automatically blocking on all I/O. The benefit would be immediate I/O call return if the requested data is already buffered and in RAM. Ideally, the I/O stream/buffer mechanism would buffer at least the amount of data requested by the previous read to that I/O source. Under this model, the first I/O request would block and yield control to another thread, but subsequent requests of the same or smaller size would return immediately. This is a file ring buffer that I have partially implemented. However, this needs a global manager so that file coherency can be maintained across multiple reads/writes to the same open file. This would be a significant increase in concurrency, which is very low today if you have a small number of threads.

This enchancement request is based on work in progress by Chris Saari.

Reassigned the bug to gordon.

Changed target milestone to M6.

Offloading some of gordon's doomage

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

Added a test to see if the async I/O request has already completed before calling WaitOnThisThread in macio.c::ReadWriteProc. In a hand timed test this shaved approx 2 seconds off apprunner startup time on my Mac (=18.5 sec vs. =20.5 seconds). Moving to M7 as additional improvments were requested in the bug report.

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

The world of file I/O in Mozilla is in flux as Necko evolves. Moving to M17 so we can re-visit this issue when Necko is more defined.

Warren, was this the Mac file i/o perf bug you were looking for?

No. I remember a mail exchange with saari about the jar protocol speeding up mac startup time, but I'm not sure if there ever was a bug for it.

I don't fully understand the proposal here. Can anyone clarify?

Revisiting old open bugs... With the impending dropping of support for Mac OS versions prior to Mac OS X and the move to a mach-o based build when Mac NSPR is basically BSD *nix NSPR can this bug be retired?

Per Wan-Teh's agreement closing WONTFIX