Status

()

Core
Networking
P3
enhancement
RESOLVED FIXED
18 years ago
16 years ago

People

(Reporter: Judson Valeski, Assigned: Darin Fisher)

Tracking

Trunk
Future
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
we need a nsIEventQueue accessor on the channels (specifically the transports)

Updated

18 years ago
Target Milestone: M15

Comment 1

18 years ago
Should this be an argument to AsyncRead/AsyncWrite instead?

Comment 2

18 years ago
The issue here is that we implicitly decide that the caller of 
AsyncRead/AsyncWrite is the thread which will receive the callback 
notifications. If this isn't true, it requires the caller to marshal over to the 
thread that will receive the notifications in order to issue the request -- an 
extra hop. If we add this attribute, we could specify the receiver event queue 
without having to do the extra hop. 

Marking enhancement.
Severity: normal → enhancement
Target Milestone: M15 → M20
(Reporter)

Comment 3

18 years ago
you mean the way it initially way :-); yes.

Comment 4

18 years ago
Moving Warren's thread bugs from his circular file to mine, because I was told it 
was the thing to do. Anyone who actually wants these bugs, now, feel free to 
correct my hastiness.
Assignee: warsome → danm

Updated

18 years ago
Target Milestone: --- → Future

Comment 5

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc
(Assignee)

Comment 6

16 years ago
bug 176919 makes this obsolete (or fixes this bug depending on how you look at
it).  users of nsITransport will be able to open async input/output streams
supporting an AsyncWait method that has a nsIEventQueue argument.  nsIChannel
consumers are stuck having to proxy the AsyncOpen call onto the right thread.

-> me
Assignee: danm → darin
Depends on: 176919
(Assignee)

Comment 7

16 years ago
FIXED with patch from bug 176919.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.