sched- async dns unix

VERIFIED FIXED in mozilla0.9

Status

()

Core
Networking
P1
normal
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: chris hofmann, Assigned: Darin Fisher)

Tracking

Trunk
mozilla0.9
x86
Windows 95
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
warren,  who gets this task for m9?
(Reporter)

Updated

19 years ago
Blocks: 10730
Summary: sched- async dns unix (intc, 2d) → sched- async dns unix (intc, 2d)

Updated

19 years ago
Assignee: warren → gordon

Comment 1

19 years ago
Gordon should be the owner, but he's working with the Intel guys on this.

Updated

19 years ago
Target Milestone: M10

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Blocks: 12836
(Reporter)

Updated

18 years ago
Target Milestone: M10 → M11
(Reporter)

Comment 2

18 years ago
m11

Updated

18 years ago
Target Milestone: M11 → M12

Updated

18 years ago
Priority: P3 → P1

Updated

18 years ago
Assignee: gordon → dp
Status: ASSIGNED → NEW

Comment 3

18 years ago
dp was handling this. Status?

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

18 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

18 years ago
Are we going to make m12 with this?

Updated

18 years ago
Target Milestone: M12 → M14

Comment 6

18 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.

Comment 7

18 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Updated

18 years ago
Blocks: 7428

Comment 8

18 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

Comment 9

18 years ago
I'll take it back to finish cancelling requests and the dns cache.
Assignee: warren → gordon

Comment 10

18 years ago
*** Bug 27505 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
We've gotta land that unix async dns code for beta2.
Keywords: beta2

Updated

18 years ago
Target Milestone: M15 → M16

Comment 12

18 years ago
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17

Updated

18 years ago
Target Milestone: M17 → M16

Updated

18 years ago
Whiteboard: no duration estimate!

Comment 13

18 years ago
I need to take look at the current state of the Intel changes before making an 

estimate.

Updated

18 years ago
QA Contact: paulmac → tever

Comment 14

18 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

Updated

18 years ago
Keywords: nsbeta2

Comment 15

18 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 16

18 years ago
I just added a blocked bug for this sucker.
Blocks: 18007

Comment 17

18 years ago
Gordon, how's this coming? Are you going to make 5/16?

Comment 18

18 years ago
I'm still optimistic about getting this done before 5/16.

Comment 19

18 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

18 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

18 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

18 years ago
Add myself to cc

Comment 23

18 years ago
this is blocking nsbeta2+ bugs, shouldn't this be nsbeta2+ then?

Comment 24

18 years ago
M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 25

17 years ago
not for beta3 either. 
Target Milestone: M16 → Future

Comment 26

17 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

Updated

17 years ago
Whiteboard: [nsbeta2-][FEATURE]3d → [nsbeta2-][FEATURE]3d[nsbeta3-]
(Assignee)

Comment 27

17 years ago
Created attachment 19624 [details] [diff] [review]
Provides serialized gethostbyname on a thread separate from the socket thread.
(Assignee)

Comment 28

17 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)

Updated

17 years ago
Blocks: 61683
(Assignee)

Comment 29

17 years ago
-> me
Assignee: gordon → darin
Status: ASSIGNED → NEW
(Assignee)

Comment 30

17 years ago
Created attachment 22709 [details] [diff] [review]
Revised previous patch for recent changes to moz-trunk.
(Assignee)

Comment 31

17 years ago
looking for an r= ...any takers??
(Assignee)

Comment 32

17 years ago
Created attachment 22726 [details] [diff] [review]
Revised patch following a review with gordon.
Blocks: 66404

Comment 33

17 years ago
hell i'll (r=rpotts)... I looked over the patch and it seemed fine to me.

Comment 34

17 years ago
looks good to me too...sr=mscott
(Assignee)

Updated

17 years ago
Target Milestone: Future → mozilla0.9
(Assignee)

Comment 35

17 years ago
Pushing this to Moz 0.9 so we can get some bake time.
(Assignee)

Comment 36

17 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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 37

17 years ago
> Consider this an intermediate solution.

Is there a followup bug?
(Assignee)

Comment 38

17 years ago
> Is there a followup bug?

See bug 70213.

Comment 39

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