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.

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.

mass move, v2. qa to me.

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

FIXED with patch from bug 176919.