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

On 12/4/09 12:50 AM, Jason Duell wrote:
> 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