Closed Bug 10733 Opened 25 years ago Closed 24 years ago

sched- async dns unix

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: chofmann, Assigned: darin.moz)

References

Details

(Whiteboard: [nsbeta2-][FEATURE]3d[nsbeta3-])

Attachments

(3 files)

Provides serialized gethostbyname on a thread separate from the socket thread.
10.18 KB, patch
Details | Diff | Splinter Review
Revised previous patch for recent changes to moz-trunk.
9.56 KB, patch
Details | Diff | Splinter Review
Revised patch following a review with gordon.
9.83 KB, patch
Details | Diff | Splinter Review 
warren,  who gets this task for m9?
Blocks: 10730
Summary: sched- async dns unix (intc, 2d) → sched- async dns unix (intc, 2d)
Assignee: warren → gordon
Gordon should be the owner, but he's working with the Intel guys on this.
Target Milestone: M10
Status: NEW → ASSIGNED
Blocks: 12836
Target Milestone: M10 → M11
m11
Target Milestone: M11 → M12
Priority: P3 → P1
Assignee: gordon → dp
Status: ASSIGNED → NEW
dp was handling this. Status?
Status: NEW → ASSIGNED
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.
Are we going to make m12 with this?
Target Milestone: M12 → M14
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.
Blocks: 7428
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
*** Bug 27505 has been marked as a duplicate of this bug. ***
We've gotta land that unix async dns code for beta2.
Keywords: beta2
Target Milestone: M15 → M16
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Target Milestone: M17 → M16
Whiteboard: no duration estimate!
I need to take look at the current state of the Intel changes before making an 

estimate.
QA Contact: paulmac → tever
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
Keywords: nsbeta2
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
I just added a blocked bug for this sucker.
Blocks: 18007
Gordon, how's this coming? Are you going to make 5/16?
I'm still optimistic about getting this done before 5/16.

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.

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."
Putting on [nsbeta2-] radar. Missed the Netscape 6 feature train.  Please set to 
MFuture.
Whiteboard: [nsbeta2+][5/16][FEATURE]3d → [nsbeta2-][FEATURE]3d
Add myself to cc
this is blocking nsbeta2+ bugs, shouldn't this be nsbeta2+ then?
M16 has been out for a while now, these bugs target milestones need to be 
updated.
not for beta3 either.
Target Milestone: M16 → Future
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
Whiteboard: [nsbeta2-][FEATURE]3d → [nsbeta2-][FEATURE]3d[nsbeta3-]
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.
Blocks: 61683
-> me
Assignee: gordon → darin
Status: ASSIGNED → NEW
looking for an r= ...any takers??
Blocks: 66404
hell i'll (r=rpotts)... I looked over the patch and it seemed fine to me.
looks good to me too...sr=mscott
Target Milestone: Future → mozilla0.9
Pushing this to Moz 0.9 so we can get some bake time.
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
> Consider this an intermediate solution.

Is there a followup bug?

> Is there a followup bug?

See bug 70213.


verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: