Closed
Bug 10733
Opened 25 years ago
Closed 24 years ago
sched- async dns unix
Categories
(Core :: Networking, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: chofmann, Assigned: darin.moz)
References
Details
(Whiteboard: [nsbeta2-][FEATURE]3d[nsbeta3-])
Attachments
(3 files)
10.18 KB,
patch
|
Details | Diff | Splinter Review | |
9.56 KB,
patch
|
Details | Diff | Splinter Review | |
9.83 KB,
patch
|
Details | Diff | Splinter Review |
warren, who gets this task for m9?
Reporter | ||
Updated•25 years ago
|
Blocks: 10730
Summary: sched- async dns unix (intc, 2d) → sched- async dns unix (intc, 2d)
Updated•25 years ago
|
Assignee: warren → gordon
Comment 1•25 years ago
|
||
Gordon should be the owner, but he's working with the Intel guys on this.
Updated•25 years ago
|
Target Milestone: M10
Reporter | ||
Updated•25 years ago
|
Target Milestone: M10 → M11
Reporter | ||
Comment 2•25 years ago
|
||
m11
Updated•25 years ago
|
Assignee: gordon → dp
Status: ASSIGNED → NEW
Comment 3•25 years ago
|
||
dp was handling this. Status?
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 4•25 years ago
|
||
Intel guys were as of last week merging their changes with gordon's mac changes. Dan Mosdale was supposed to talk with them to improve on their technique. I will talk to all of them and see where we are with this.
Comment 5•25 years ago
|
||
Are we going to make m12 with this?
Updated•25 years ago
|
Target Milestone: M12 → M14
Comment 6•25 years ago
|
||
It turns out that doing more than the current plan requires a non-trivial amount of work. And although the current plan is sub-optimal, it's as good as what we've got in the Communicator. Given this, Brendan has convinced me that I should devote my time to higher priority mozilla problems that still need work (eg performance). For those who care about ways to make DNS better, I've detailed what I think is the right thing to do in a recent .netlib thread.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Comment 8•25 years ago
|
||
Unix DNS requests happen on a separate socket transport thread and I have testing it and they dont freeze the entire app. This isn't critical for beta anymore. Cancelling the request is going to be the thing that needs to get implemented. Reassigning to warren. Marking M15.
Assignee: dp → warren
Status: ASSIGNED → NEW
Target Milestone: M14 → M15
I'll take it back to finish cancelling requests and the dns cache.
Assignee: warren → gordon
Comment 10•25 years ago
|
||
*** Bug 27505 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Updated•24 years ago
|
Target Milestone: M17 → M16
Updated•24 years ago
|
Whiteboard: no duration estimate!
Comment 13•24 years ago
|
||
I need to take look at the current state of the Intel changes before making an estimate.
Updated•24 years ago
|
QA Contact: paulmac → tever
Comment 14•24 years ago
|
||
My current estimate for this is 3 days.
Status: NEW → ASSIGNED
Summary: sched- async dns unix (intc, 2d) → sched- async dns unix
Whiteboard: no duration estimate! → 3d
Comment 15•24 years ago
|
||
Putting on [nsbeta2+] radar. But MUST complete work by 05/16 or we may pull this feature for PR2.
Keywords: beta2
Whiteboard: 3d → [nsbeta2+][5/16][FEATURE]3d
Comment 17•24 years ago
|
||
Gordon, how's this coming? Are you going to make 5/16?
Comment 18•24 years ago
|
||
I'm still optimistic about getting this done before 5/16.
Comment 19•24 years ago
|
||
wtc asked me why jwz's async dns code has a "middle" process, a child of mozilla which in turn forks off the actual worker processes. I believe that there are two reasons: first, the initial fork is done very early on when mozilla is quite small. This keeps the middle process (and therefore the child processes) quite small. If you'd waited until you needed a dns query to do the fork, that new process would be unnecessarily huge, because mozilla is huge. It's getting better nowadays, but there are still platforms that don't handle fork() of a big process well. Second, it turns all the events into messages on a socket which can be select()'d upon. Among other benefits, this keeps the kill/reap code in once small place without any unnecessary blocking. Not all platforms can handle zombieless children, and byzantine networking code is a bad place to have to remember to reap. (And of course zombie leaks are very bad.) jwz's code should be compilable standalone for testing purposes (there's an #ifdef'd main() function and everything) so there shouldn't be any real need to "simplify" his model.
Comment 20•24 years ago
|
||
The following Unix platforms have native pthreads. 1. Linux, recent releases. 2. Solaris, 2.5.1 or later 3. FreeBSD, recent releases 4. HP-UX, 11.00 5. IRIX, 6.3 or later 6. AIX, 4.1 or later 7. Digital/Tru64 UNIX, V4.0 or later Note that it may be necessary to serialize all the gethostbyname() calls with a lock if the result is returned in a static buffer and the reentrant gethostbyname_r() is not available. For more information, see NSPR bug #26506, "The DNS lock is not needed with native threads."
Comment 21•24 years ago
|
||
Putting on [nsbeta2-] radar. Missed the Netscape 6 feature train. Please set to MFuture.
Whiteboard: [nsbeta2+][5/16][FEATURE]3d → [nsbeta2-][FEATURE]3d
Comment 22•24 years ago
|
||
Add myself to cc
Comment 23•24 years ago
|
||
this is blocking nsbeta2+ bugs, shouldn't this be nsbeta2+ then?
Comment 24•24 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be updated.
Comment 26•24 years ago
|
||
gordon, how far did you get on this? Could you post your patches to this bug? Adding nsbeta3 keyword to this, to make the PDT justify not fixing this bug even though it blocks a lot of other important bugs.
Keywords: nsbeta3
Assignee | ||
Comment 27•24 years ago
|
||
Assignee | ||
Comment 28•24 years ago
|
||
I just attached a patch for this bug. This is not a true async DNS implementation. Instead (without requiring an upgrade to NSPR 4.1) it queues up DNS requests and processes them one-by-one on a worker thread. This is not a polished implementation, but I've tested it, and it works.
Assignee | ||
Comment 30•24 years ago
|
||
Assignee | ||
Comment 31•24 years ago
|
||
looking for an r= ...any takers??
Assignee | ||
Comment 32•24 years ago
|
||
Comment 33•24 years ago
|
||
hell i'll (r=rpotts)... I looked over the patch and it seemed fine to me.
Comment 34•24 years ago
|
||
looks good to me too...sr=mscott
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9
Assignee | ||
Comment 35•24 years ago
|
||
Pushing this to Moz 0.9 so we can get some bake time.
Assignee | ||
Comment 36•24 years ago
|
||
Patch checked in. Resolving this bug as FIXED even though we want to rework the solution once NSPR 4.1 lands. Consider this an intermediate solution. It just gets DNS lookups off the socket thread so existing socket transports aren't blocked by a new lookup.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 37•24 years ago
|
||
> Consider this an intermediate solution.
Is there a followup bug?
Assignee | ||
Comment 38•24 years ago
|
||
> Is there a followup bug? See bug 70213.
You need to log in
before you can comment on or make changes to this bug.
Description
•