Necko e10s 1st cut design: slow vs premature optimization?

[Jason Duell]

So far for necko e10s I've been trying to design in what seem like
sensible optimizations up front (not creating the parent channel until
AsyncOpen time, copying the entire request/response headers once at
request/reply time to avoid IPC traffic, etc.) while I code. But I'm
starting to suspect that I may be able to get something working sooner
by using a simpler "remote object" model, where I avoid subtle issues
of keeping the chrome/tab channels in sync by just proxying everything
possible (each set/get method, etc.) to the chrome channel, while
keeping the tab HTTP channel as dumb and stateless as possible. This
will result in potentially lots of IPC traffic, but I figure that can
be optimized piece by piece later (based on IPC traffic profiles), and
will get us a working e10s HTTP faster.

Any objections?

[Benjamin Smedberg]

Post by Jason Duell
So far for necko e10s I've been trying to design in what seem like
sensible optimizations up front (not creating the parent channel until
AsyncOpen time, copying the entire request/response headers once at
request/reply time to avoid IPC traffic, etc.) while I code. But I'm
starting to suspect that I may be able to get something working sooner
by using a simpler "remote object" model, where I avoid subtle issues
of keeping the chrome/tab channels in sync by just proxying everything
possible (each set/get method, etc.) to the chrome channel, while
keeping the tab HTTP channel as dumb and stateless as possible. This
will result in potentially lots of IPC traffic, but I figure that can
be optimized piece by piece later (based on IPC traffic profiles), and
will get us a working e10s HTTP faster.
Any objections?

There are two issues here, speed and correctness. I agree that optimizing
for speed now is probably not worthwhile. But I do think we want to avoid
various correctness issues up front. In particular:

* Channel state may change on the chrome side in ways which are inconsistent
with what the content side expects. Once the channel is opened, are channel
properties immutable (properties which may be get/set)? Once a channel
closes, for example, will the header and security data still be available?

* Will setting a property cause side effects which might re-enter in strange
ways? How will notifications (redirects, ondataavailable, etc) interact with
with these synchronous IPC messages? Is it possible that an ondataavilable
handler in the child (for example) might end up re-entering itself?

--BDS

[Jason Duell]

Post by Benjamin Smedberg
* Channel state may change on the chrome side in ways which are inconsistent
with what the content side expects. Once the channel is opened, are channel
properties immutable (properties which may be get/set)? Once a channel
closes, for example, will the header and security data still be available?

I'll have to look at the mutability/immutability of properties and how
it affects things. But this is actually more likely to bite me if I'm
trying to keep a fat tab channel "in sync" with the chrome channel's
state.

I'm hoping that by keeping a reference to the chrome channel I can
ensure that I can keep asking it for headers, etc. after it would
normally be closed and cleaned up. Will have to check that too.

Post by Benjamin Smedberg
* Will setting a property cause side effects which might re-enter in strange ways? How will notifications (redirects, ondataavailable, etc) interact with with these synchronous IPC messages? Is it possible that an ondataavilable handler in the child (for example) might end up re-entering itself?

So all sync msgs will be from the child to the parent ("GetFoo",
etc.). Async notifications like OnDataAvailable should just be queued
until the sync GetFoo method is complete, right? Can you describe the
problem you're thinking of a bit more?

[Benjamin Smedberg]

Post by Jason Duell
I'll have to look at the mutability/immutability of properties and how
it affects things. But this is actually more likely to bite me if I'm
trying to keep a fat tab channel "in sync" with the chrome channel's
state.

I don't think this is true, from the client's perspective. If you have a
"fat channel", the state can safely diverge between the child and the
parent, as long as each asynchronous message updates the state correctly.
For example, imagine that a channel gets disconnected in the middle of
processing:

Content is handling an asynchronous onDataAvailable message. On the content
side, the nsIRequest.status should be NS_OK and nsIRequest.isPending should
be true.

Simultaneously on the chrome side, the TCP channel is dropped and
onStopRequest is fired with the errors. nsIRequest.status is going to be a
failure code and nsIRequest.isPending will be false.

Post by Jason Duell
So all sync msgs will be from the child to the parent ("GetFoo",
etc.). Async notifications like OnDataAvailable should just be queued
until the sync GetFoo method is complete, right? Can you describe the
problem you're thinking of a bit more?

I don't know whether they will be queued. In theory, there could be pending
messages when you make the synchronous call, and it would break in-order
delivery to process the synchronous response while those messages are
pending. But I don't actually know the semantics that are implemented.

--BDS

[Chris Jones]

Post by Benjamin Smedberg

Post by Jason Duell
So all sync msgs will be from the child to the parent ("GetFoo",
etc.). Async notifications like OnDataAvailable should just be queued
until the sync GetFoo method is complete, right? Can you describe the
problem you're thinking of a bit more?

I don't know whether they will be queued. In theory, there could be
pending messages when you make the synchronous call, and it would break
in-order delivery to process the synchronous response while those
messages are pending. But I don't actually know the semantics that are
implemented.

Sync messages guarantee no re-entry. If async messages are sent from
the parent while it's processing the sync in-msg, they're queued to be
processed in the child until the sync response is received. The
semantics are eminently changeable though, especially since I don't
think any current protocols do this.

Cheers,
Chris

[Jason Duell]

Post by Benjamin Smedberg
I don't think this is true, from the client's perspective. If you have a
"fat channel", the state can safely diverge between the child and the
parent, as long as each asynchronous message updates the state correctly.

You're right. We're going to want an async model for performance, and
I've already started down that road, so I think I'll stay on it,
rather than open new cans o' worms.

thanks.

J