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

On 12/4/09 10:21 AM, Jason Duell wrote:

> 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.

> 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