we need a nsIEventQueue accessor on the channels (specifically the transports)
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
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
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.