Closed
Bug 93582
Opened 23 years ago
Closed 23 years ago
nsFileChannel::AsyncOpen synchronously stat's the file before returning
Categories
(Core :: Networking: File, defect, P3)
Core
Networking: File
Tracking
()
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: darin.moz, Assigned: darin.moz)
References
()
Details
(Keywords: perf, Whiteboard: r=gordon, sr=dougt, fixed-on-trunk, verified-on-trunk)
Attachments
(2 files)
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
nsFileChannel::AsyncOpen synchronously stat's the file before returning. This
seems wrong since AsyncOpen should be doing this "asynchronously" to avoid
delaying the calling thread. This seems like a definite performance hit.
|
Assignee | |
Comment 1•23 years ago
|
||
|
|
Assignee | |
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → mozilla0.9.4
|
|
Assignee | |
Comment 2•23 years ago
|
||
this code was added as part of the solution for bug 69134.
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 3•23 years ago
|
||
this bug may have a noticeable impact on startup time.
Keywords: patch
|
|
Assignee | |
Comment 4•23 years ago
|
||
... as well as cached page load times.
|
||
Comment 5•23 years ago
|
||
Please ensure that http://bugzilla.mozilla.org/show_bug.cgi?id=69134 is not
reproducible with your fix.
|
|
Assignee | |
Comment 6•23 years ago
|
||
|
|
Assignee | |
Comment 7•23 years ago
|
||
i could not reproduce bug 69134 with this patch applied.
also, i removed some redundant code from nsFileChannel::OnDataAvailable. there
was code to cancel out the file transport read request on failure, but
cancelation would occur anyways if OnDataAvailable returns failure, so the
explicit call to Cancel is completely unnecessary.
|
|
Assignee | |
Comment 8•23 years ago
|
||
gordon, dougt: can i get r/sr= from you guys on this patch?
|
|
||
Comment 9•23 years ago
|
||
why did you remove the deathgrip:
nsCOMPtr<nsIStreamListener> tempListener = this;
Not sure exactly why it is there though.
|
|
Assignee | |
Comment 10•23 years ago
|
||
it's not a deathgrip because we can assume that the caller holds an owning
reference to the file channel for the duration of AsyncOpen.
|
||
Comment 11•23 years ago
|
||
r=gordon
|
|
||
Comment 12•23 years ago
|
||
after looking at it, this deathgrip is useless. sr=me
|
|
Assignee | |
Updated•23 years ago
|
Whiteboard: r=gordon, sr=dougt
|
|
Assignee | |
Comment 13•23 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: r=gordon, sr=dougt → r=gordon, sr=dougt, fixed-on-trunk
|
||
Comment 15•23 years ago
|
||
Am I looking for anything besides the lack of a crash (absence of regression of
bug 69134 from fixing this bug)?
Passed standard "file URL to non-existent file" tests. Some minor problems to be
filed that are cosmetic.
VERIFIED (on-trunk)
MacOSX 2001-09-05-05
Win32 2001-09-05-03
Linux 2001-09-05-08
Whiteboard: r=gordon, sr=dougt, fixed-on-trunk → r=gordon, sr=dougt, fixed-on-trunk, verified-on-trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•