Status

enhancement
P3
normal
RESOLVED WONTFIX
21 years ago
17 years ago

People

(Reporter: gordon, Assigned: sdagley)

Tracking

other
Future
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

21 years ago
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.
Reporter

Comment 1

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

Updated

21 years ago
Assignee: wtc → gordon

Comment 2

21 years ago
Reassigned the bug to gordon.
Reporter

Updated

21 years ago
Status: NEW → ASSIGNED

Updated

21 years ago
Target Milestone: M6

Comment 3

21 years ago
Changed target milestone to M6.
Assignee

Updated

21 years ago
Assignee: gordon → sdagley
Status: ASSIGNED → NEW
Assignee

Comment 4

21 years ago
Offloading some of gordon's doomage

Comment 5

21 years ago
NSPR now has its own Bugzilla product.  Moving this bug to the NSPR product.
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Assignee

Updated

20 years ago
Target Milestone: M6 → M7
Assignee

Comment 6

20 years ago
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.
Assignee

Updated

20 years ago
Target Milestone: M7 → M8
Assignee

Updated

20 years ago
Severity: normal → enhancement
Assignee

Updated

20 years ago
Target Milestone: M9 → M11
Assignee

Updated

20 years ago
Target Milestone: M11 → M14

Comment 7

20 years ago
phillip gone, removing him from qa contact, sorry for spam
Assignee

Updated

20 years ago
Target Milestone: M14 → M17
Assignee

Comment 8

20 years ago
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.

Comment 9

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

Comment 10

20 years ago
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.

Updated

19 years ago
Target Milestone: M17 → Future
I don't fully understand the proposal here. Can anyone clarify?
Assignee

Comment 12

17 years ago
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?

Assignee

Comment 13

17 years ago
Per Wan-Teh's agreement closing WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.