Closed Bug 572640 Opened 14 years ago Closed 14 years ago

e10s HTTP: Serialize nsIMultiplexInputStreams

Categories

(Core :: Networking: HTTP, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lusian, Unassigned)

References

Details

Attachments

(1 file)

Attached patch wip (deleted) — Splinter Review
I am stuck here. I can't make this patch call the right WriteParam/ReadParam for each substream because of ParamTraits<nsIInputStream*>, but ParamTraits<nsIInputStream*> is there to make it compile.
You can do what we did for URI's -- have the various stream implementations inherit from nsIIPCSerializable, and then implement them like so: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp#2886 Then in ParamTraits<nsIMultiplexInputStream*>::Write(), you just QI to nsIIPCSerializable (and explode if you can't); then call its Write method. Note that you'll also have to get the CID of the implementation (e.g. http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/NeckoMessageUtils.h#103), so you can instantiate it on the other side. You should be able to use that ParamTraits<URI> code as a model.
> Then in ParamTraits<nsIMultiplexInputStream*>::Write(), you just > QI to nsIIPCSerializable (and explode if you can't) More politely, you could also check that the QI works before you call the IPDL function, and fail gracefully at that point. There is no graceful fail once you're within ParamTraits<>.
I am confused. Jason's description in Bug 564553 says that I reconstruct the new stream in chrome, but if I follow this > You can do what we did for URI's -- have the various stream implementations > inherit from nsIIPCSerializable, and then implement them like so: > http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp#2886 how am I going to reconstruct the stream in Read()? Is this ( http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/PHttpChannelParams.h#198) even necessary?
(In reply to comment #2) > More politely, you could also check that the QI works before you call the IPDL > function, and fail gracefully at that point. There is no graceful fail once > you're within ParamTraits<>. Hmm. I'm not sure which approach I like better -- not being able to serialize something should be pretty fatal, IMO. Especially since this stuff could be called from within another Write method, where there's no graceful fail. Doing the QI first makes things kinda ugly. If we wanted to do this, the better approach would be to change the signature of Write() to have a bool return value such that consumers can gracefully fail in general. Unrelated -- you could instead implement your ParamTraits<nsIMultiplexedInputStream*> as a generic ParamTraits<nsIInputStream*>, and have the multiplexed stream implementation of nsIIPCSerializable do the right thing. (In reply to comment #3) > how am I going to reconstruct the stream in Read()? Is this ( > http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/PHttpChannelParams.h#198) > even necessary? No, you'll have to move (part of) that code into the string input stream implementation of nsIIPCSerializable. You can follow the example of http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/NeckoMessageUtils.h#114.
dan, is this r-? If so, lets mark it!
Attachment #451892 - Flags: review-
Will be fixed by Bug 564553
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: