On 1/4/16 5:27 PM, Jason Duell wrote:
That makes sense, except I'm not sure how to split it apart. Are there any
examples of what such a parent-child protocol handler should look like in a
basic sense? The p-c goop in netwerk/protocol/ is not really amenable to
determining this, not least of which being written in C++.
The way the builtin protocols (HTTP/FTP/Websockets/etc) handle this is that
the protocol handler code checks whether we're in a child process or not
when a channel is created, and we hand out different things depending on
that. In the parent, we hand out a "good old HTTP channel" (nsHttpChannel)
just as we've always done in single-process Firefox. In the child we hand
out a stub channel (HttpChannelChild) that looks and smells like an
nsIHttpChannel, but actually uses IPDL (our C++ cross-platform messaging
language) to essentially shunt all the real work to the parent. When
AsyncOpen is called on the child, the stub channel winds up telling the
parent to create a regular "real" http channel, which does the actual work
of creating/sending an HTTP request, and as the reply come back, sending
the data to the child, which dispatches OnStart/OnData/OnStopRequest
messages as they arrive from the parent.
This seems rather complex (I'm reading the HttpChannelChild code right
now). Was there a particular reason for doing it that way?
If the child did all the channel work, etc., would that be fine too?
When the child finishes transferring data, does it or the parent have to
do anything else special?
Hopefully this will
get you started, along with this inspirational gopher:// video:
https://www.youtube.com/watch?v=WaSUyYSQie8
:)
It's in the hole!
Cameron Kaiser
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
