Closed Bug 30892 Opened 25 years ago Closed 22 years ago

event Q attribute

Categories

(Core :: Networking, enhancement, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: jud, Assigned: darin.moz)

References

Details

we need a nsIEventQueue accessor on the channels (specifically the transports)
Target Milestone: M15
Should this be an argument to AsyncRead/AsyncWrite instead?
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
you mean the way it initially way :-); yes.
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
Target Milestone: --- → Future
mass move, v2.
qa to me.
QA Contact: tever → benc
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
FIXED with patch from bug 176919.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.